[wp-trac] [WordPress Trac] #40063: Handle site cache invalidation more specifically for option updates

[WordPress Trac]

#40063: Handle site cache invalidation more specifically for option updates
--------------------------------+-------------------------
 Reporter:  flixos90            |      Owner:
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  4.7.4
Component:  Networks and Sites  |    Version:
 Severity:  normal              |   Keywords:  needs-patch
  Focuses:  multisite           |
--------------------------------+-------------------------
 As discussed during today's multisite office-hours, there are a few issues
 in how the cache is currently invalidated when updating options.

 * `update_blog_option()` should no longer call `refresh_blog_details()`.
 This was already almost removed in #26410, and there is no value in having
 this any longer, as options are generally not part of any site cache.
 * In `wp-includes/ms-default-filters.php` the options `blogname`,
 `siteurl` and `post_count` trigger a `refresh_blog_details()` call which
 itself calls `clean_blog_cache()`. That happens because these fields are
 part of a `WP_Site` object through the special site details functionality.
 However, `clean_blog_cache()` invalidates the entire site's cache
 including reset of `last_changed` which is unnecessary here. Instead of
 hooking `refresh_blog_details()` into these option updates, let's create a
 new function that only runs `wp_cache_delete( $blog_id , 'blog-details' )`
 and `wp_cache_delete( $blog_id, 'site-details' )`.
 * For some reason the `home` option is not part of the group of the above
 3 options, although it's also part of site details. So let's hook the new
 function into an option update for `home` as well.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40063>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform