Handle site cache invalidation more specifically for option updates
|Reported by:||flixos90||Owned by:||flixos90|
|Component:||Networks and Sites||Keywords:||has-patch has-unit-tests commit fixed-major|
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.
Change History (16)
6 weeks ago
- Keywords fixed-major added
- Resolution fixed deleted
- Status changed from closed to reopened
Note: See TracTickets for help on using tickets.