[wp-trac] [WordPress Trac] #27003: Introduce wp_get_network() and begin cleanup of multisite load

WordPress Trac noreply at wordpress.org
Wed Mar 5 06:38:08 UTC 2014


#27003: Introduce wp_get_network() and begin cleanup of multisite load
----------------------------+------------------------
 Reporter:  jeremyfelt      |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  3.9
Component:  Bootstrap/Load  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  needs-testing   |     Focuses:  multisite
----------------------------+------------------------

Comment (by nacin):

 Deprecating something in load.php or ms-load.php is tough because these
 files are available earlier than deprecated.php or ms-deprecated.php would
 be. If someone is calling get_current_site_name() in sunrise.php this
 would turn into a fatal error.

 get_current_site_name() is for populating the object with the site_name
 property. While it accepts a $current_site, it is before $wpdb->siteid is
 actually set, which means get_site_option() doesn't actually work as a
 replacement. That's why it does these weird direct DB queries and cache
 calls, and that's why I side-stepped it and chose to set site_name after
 the fact.

 If wp_get_network() returned a WP_Network object we could lazy-load
 site_name and it wouldn't be a problem. But we have no proper way to
 "switch" to a network so it's not like we could make get_site_option() do
 what we wanted it to do.

 get_current_site()->site_name is used in a decent number of places.
 However, the changes I referenced earlier also mean that site_name will be
 set even if sunrise had set $current_site and $current_blog (it got pulled
 out of the conditional), thus it doesn't matter if it doesn't do anything.

 ----

 Seems like our default handling of cookie domains was always such that we
 assumed the current network would completely encompass all domains on that
 respective network. That, obviously, is wrong. I imagine if a site doesn't
 match a network now, with no special handling (a plugin, etc.),
 COOKIE_DOMAIN would be set to the network, and the site wouldn't have
 functioning cookies? If so, then we could aim to think outside the box a
 bit here.

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


More information about the wp-trac mailing list