[wp-trac] [WordPress Trac] #37958: Improve looping through sites and restoring

[WordPress Trac]

#37958: Improve looping through sites and restoring
--------------------------------+-------------------------------------
 Reporter:  tfrommen            |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:                      |     Focuses:  multisite, performance
--------------------------------+-------------------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:12 tfrommen]:
 > Did you have a look at the patch? :)

 Yes.

 > I don't see anything in storing and restoring a single (!) site state
 that really urges to be handled similar to stacking up locales.

 There are 4 methods for switching:

 * `switch_to_locale()`
 * `restore_previous_locale()`
 * `restore_current_locale()`
 * `change_locale()`

 > Or, in other words, what is it that you don't like in the current patch
 (and thus idea)?

 I like the idea, because it's what the Locale switcher already does. I
 don't like the patch because states are already a named thing in
 WordPress, typically meaning a combination of statuses. While sites aren't
 filterable yet, they should be soon (see #37684) and these names would
 conflict, creating more & different confusion.

 It's also too ambiguous: `state` could mean visibility, status,
 availability, or any combination there-of, but actually means none of
 those things in this implementation.

 Historically, what you're proposing is originally how the site-switching
 API worked (back in 2005) but as a whole we've decided long ago to always
 switch back to the current site as quickly as possible, for two reasons:

 * maintain code clarity
 * not accidentally avoid actions or filters running deep in the stack
 (that might not be obvious in the current scope)

 We decided on `stack` because that's how it works. It's an ordered array
 of sites in a stack, and you can traverse as deep into that stack (and
 back out again) as you'd like for your given purpose.

 There isn't anything wrong with "stack" other than it being foreign, and
 since developers aren't exposed to the name of the globals, it doesn't
 even really effect anyone other than people working on core, which makes
 the overhead for re-learning a 10 year old API high with a low return
 value because we still need to maintain the old global incase someone
 touches it manually.

 Phew!

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37958#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform