WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 7 months ago

#40063 closed defect (bug) (fixed)

Handle site cache invalidation more specifically for option updates

Reported by: flixos90 Owned by: flixos90
Milestone: 4.7.4 Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: has-patch has-unit-tests commit fixed-major
Focuses: multisite Cc:

Description

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.

Attachments (2)

40063.diff (2.1 KB) - added by flixos90 8 months ago.
40063.2.diff (6.1 KB) - added by flixos90 7 months ago.

Download all attachments as: .zip

Change History (16)

@flixos90
8 months ago

#1 @flixos90
8 months ago

  • Keywords has-patch needs-unit-tests added; needs-patch removed

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

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


7 months ago

@flixos90
7 months ago

#3 @flixos90
7 months ago

  • Keywords has-unit-tests commit added; needs-unit-tests removed

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

#4 @swissspidy
7 months ago

  • Owner set to flixos90
  • Status changed from new to assigned

Looks good to me.

#5 @flixos90
7 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#6 @swissspidy
7 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

#7 @ocean90
7 months ago

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.

#8 @johnjamesjacoby
7 months ago

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.

#9 @flixos90
7 months ago

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.

#10 @swissspidy
7 months ago

In 40333:

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

See #40063.

#11 @swissspidy
7 months ago

In 40334:

Themes: Fix incorrect annotation for __clear_multi_author_cache() function.

Props flixos90.
See #40063.
Fixes #40262.

#12 follow-up: @swissspidy
7 months ago

@ocean90 Still got objections for a 4.7.4 merge?


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

#13 in reply to: ↑ 12 @ocean90
7 months ago

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.

#14 @swissspidy
7 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.