[wp-trac] [WordPress Trac] #40228: Use get_sites in get_blog_details

[WordPress Trac]

#40228: Use get_sites in get_blog_details
-------------------------------------------------+-------------------------
 Reporter:  spacedmonkey                         |       Owner:  flixos90
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  4.9
Component:  Networks and Sites                   |     Version:
 Severity:  blocker                              |  Resolution:
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:  multisite
  feedback ms-roadmap                            |
-------------------------------------------------+-------------------------
Changes (by westi):

 * severity:  normal => blocker


Comment:

 I think it is more nuanced than that but lets compare in detail to see.

 The current release version of `get_blog_details` leverages caching as
 follows:

 1) `blog-lookup` cache for converting domain + path => blog_id
 2) `blog-details` cache for converting a blog_id => The response of
 `get_blog_details`
 3) `sites` cache (inside WP_Site) to populate the WP_Site object on
 construction via `get_instance`
 4) `site-details` cache - This is potentially used for the extended
 properties on the `WP_Site` object but not directly by `get_blog_details`
 as it sets the extended properties itself by switching and calling
 `get_option`

 This gives us up to four different cache groups being used, which are all
 global groups keyed by blog_id and invalidation only happens to cache
 items when the object they reference has changed - i.e. invalidation is
 tied to mutation of the state of a blog_id.

 The code in trunk leverages caching as follows:

 `get_blog_details` calls `get_site_by` calls `get_sites` calls
 `WP_Site_Query::query` calls `WP_Site_Query::get_sites` this path
 leverages caching as follows:

 1) `sites` cache inside `WP_Site_Query::get_sites` which is keyed off a
 cache key based on the query and last_changed timestamp for sites.
 2) `_prime_site_caches` is called with the list of found IDs to prime the
 `sites` cache group with the `wp_blogs` data for each found ID
 3) `get_site` is called for each id to get the `WP_Site` object which uses
 the existing or primed data in the `sites` cache group.

 So yes, maybe bringing back the `blog-lookup` cache would make this change
 safer, but also I think we need to not call `get_site_by` if we have a
 `blog_id` and we should review and document the change in query count and
 complexity when the caches are all empty.

 Side note: is WP_Site_Query safe for large multi-site installs aka does it
 self neuter bad queries?

 Also, I think this ticket is now a blocker for 4.9?

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