[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):

 Yeah, so, [attachment:27003.13.diff] is a pretty sharp departure from how
 multisite site detection works now, which starts with identifying the
 network. The patch tries hard to find the site first, then use the site's
 network ID to set the current network. To find a site, it takes the domain
 plus the first path segment. Now, that doesn't always work:

  * If we're dealing with a "subdirectory" install, our network may have a
 path. (A "subdomain" install, which really is an "anything goes" install,
 ideally does not have a network path.) So we need to identify the network
 first, then use the first path segment following the network's path
 segment to identify the site.

  * If constants are defined for the network (as they are per
 instructions), then we can simply use those first. Note the patch doesn't
 currently then restrict the resulting site to that network. In fact in 3.8
 if the located site isn't on the declared network, then it resets the
 network object anyway. (There was actually no reason to find the network
 first in 3.8.) I've updated that in [attachment:27003.14.diff], otherwise
 the same as 13.diff.

 It also tries to optimize for some common situations. Some notes:

  * If it's a "subdirectory" situation where constants are not defined, it
 queries the DB to see if there are even two networks installed. If there's
 just one, then that's obviously our network, and it caches it (just as it
 did in 3.8). While constants are going to be in place almost always, when
 they're not, jeremyfelt and I had agreed in IRC that it's going to be more
 common for a single network to be used.

  * If you're running an external object cache, it caches whether any
 network has a path. If none do, then it can bypass querying the networks
 table for paths all together, which results in a much cleaner (and much
 more easily cached) query.
  * It's probable that these should be network transients.

  * Filters are in place to not only short-circuit the site-finding code
 all together, but to also specifically declare how many path segments are
 in play. So an install could say that domain X actually has sites for two
 path segments, while domain Y has none. If we're dealing with a
 "subdomain" only install, then trying to query for every single path is a
 terrible query. To avoid that, a future patch should use the external
 object cache to see if any sites at all have a path. This is more or less
 necessary to maintain the same performance of subdomains pre-patch.

  * It requires additional caching, and needs a review from pento for how
 to best make these queries. I went for fewest queries possible when in
 reality it might make more sense to add a few more queries but be sure
 they are being cached to a T.

  * Because this code opens up the possibility that *any* initial path
 segment is actually a site, this can cause some performance issues. At
 least with subdomains you have DNS to prevent essentially random strings
 in a URL from causing a boatload of queries — and, yes, even flooding
 memcache. (If using a wildcard DNS, then the whole redirect-to-signup
 kicks in.) These queries are not the absolute cheapest and haven't been
 tested against a massive blogs table, yet.

 There are likely further optimizations to make (not to mention a number of
 declared @todo's), there are likely some assumptions made that will need
 to be challenged (for example — can a subdomain install have a network
 path, as it exists now?), and it needs a lot of unit tests. Also, the
 `*_by_path_segments_count` filter names aren't great. But it's a great
 step forward.

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