Handle site cache invalidation more specifically for option updates

[flixos90]

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.

[flixos90]

40063.diff​ fixes this. We should probably add a few unit tests to make sure the cache is properly invalidated for the four options.

[flixos90]

40063.2.diff​ provides unit tests to verify these things now work as expected.

[swissspidy]

Looks good to me.

[flixos90]

In 40305:

Multisite: Handle sites cache invalidation more granularly for option updates.

Previously update_blog_option() would trigger an invalidation of that site's entire cache although these changes did not affect the content of these caches. Furthermore changes to the special options blogname, siteurl and post_count should not invalidate the entire cache of that site, but only their respective site details cache. The option home now has the same behavior as it also belongs to the site details, but did not invalidate the cache at all previously.

Several new unit tests confirm these changes work as expected.

Fixes #40063.

[ocean90]

To me that looks like a big change which you want to ship in a minor version. I think it needs some more soak time to get it tested on w.org and maybe even wp.com (@stephdau) . Did you check that [40305] doesn't revert #15605?

What's the reason behind making the new function "private"? @private doesn't seem to be an official PHPDoc tag and all the other clean_* functions are without an underscore as well.

[johnjamesjacoby]

I agree with @ocean90 that the underscore and @private should be removed.

I don't think #15605 is a concern. Overall, this change results in fewer iterations through the cache process when unrelated options are changed, and more accurate cache invalidation when home is changed.

[flixos90]

I had seen the @private in core somewhere, so for some reason I thought it was the way to go (e.g. __clear_multi_author_cache(), though that's obviously really old). I agree that doesn't really make sense.

Regarding the change, I think it is good to go into a minor release (now with the new cycle at least). It's not a regression, but a minor bugfix (regarding the missing home) and improvement (less aggressive cache invalidation) where I don't see problems arising from. I'd personally lean towards backporting it for 4.7.4.

[swissspidy]

In 40333:

Multisite: After [40305], rename clean_site_details_cache() method as it's not really private.

See #40063.

[swissspidy]

In 40334:

Themes: Fix incorrect annotation for __clear_multi_author_cache() function.

Props flixos90.
See #40063.
Fixes #40262.

[swissspidy]

@ocean90 Still got objections for a 4.7.4 merge?

---

@stephdau Wanna weigh in with feedback from WordPress.com?

[ocean90]

Replying to swissspidy:

@ocean90 Still got objections for a 4.7.4 merge?

I don't think so, not aware of any issues on w.org so far.

[swissspidy]

In 40385:

Multisite: Handle sites cache invalidation more granularly for option updates.

Previously update_blog_option() would trigger an invalidation of that site's entire cache although these changes did not affect the content of
these caches. Furthermore changes to the special options blogname, siteurl and post_count should not invalidate the entire cache of that site, but only their respective site details cache. The option home now has the same behavior as it also belongs to the site details, but did not invalidate the cache at all previously.

Several new unit tests confirm these changes work as expected.

Fixes #40063.

Merges [40305] and [40333] to the 4.7 branch.