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

[WordPress Trac]

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

Comment (by nacin):

 At the time of these new filters, plugin.php and functions.php are loaded
 — and little else. jeremyfelt points out that these filters mean you won't
 need to do much domain/path/network/site manipulation in sunrise anymore,
 but you'll need to use a sunrise file to actually register your plugin
 callbacks. I find that to be OK. It ends up being much easier in some
 respects.

 Say make.wordpress.org was our network and /core/ was our site, and then
 we wanted to add a /core/handbook/ site. (I had to do this at one point
 via a nice hack; though they're merged now.) It'd be easy for me to use
 the site_by_path_segments_count filter to change the 1 segment to a 2 when
 the requested path starts with /core, or more so /core/handbook. Or I
 could use the pre_* filter to actually return a site object (we'll need a
 wp_get_site() to match wp_get_network() and to replace basic usage of
 get_blog_details()) for exact matches.

 Of course, you could also just do $current_site = wp_get_network( X ) and
 $current_blog = wp_get_site( X ). It really depends what kind of lifting
 you want to do and where you want it done. If you had a second level of
 path segments you wanted considered on a dynamic basis (so not simply
 "handbook") then passing this off to find_site_by_path() will make your
 life easier.

 And then there's the question: why limit it to just one path segment by
 default? Mainly because it's so dang hard to predict and optimize for all
 of the setups out there. You might have a network with thousands of sites,
 all with a path of / (so, domains or subdomains), yet you'll need to take
 the entire URL (/2012/01/05/something/page/2/feed/whatever/) and check to
 see if any of those path segments add up to a site. That means a unique
 query for every single URL hitting the install, which is a nightmare to
 cache.

 Now, you could query for all sites on that domain, cache those results,
 and then simply see if any of the paths match up, but how do I know if
 it's one site with a path of /, or if *every* one of those thousands of
 sites are on that particular domain?

 There are only so many "large" networks out there (networks with > 10,000
 sites) that would run into performance issues; it's possible we could have
 different optimization "tracks" depending on the kind and size of install
 you're running. That's kind of what the proposed filters start to get at,
 by letting you control the path segments.

 I do think we can get smarter here, and these patches make some headway,
 but it's not straightforward.

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