Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the Change
This PR implements the ability to make use of
wp_cache_get_last_changed()
for ElasticPress, identifying the last time a modification was made to an index. Both for the current blog / site and the entire network / Multisite. This is borrowed from WordPress Core's use ofwp_cache_get_last_changed( 'posts' )
(and others) which can be a good way of identifying whenever a post, irrespective of post type or type of update, has occurred.Alternate Designs
None were considered, as the source / inspiration seem a foundational feature being introduced to ElasticPress from WordPress Core.
Benefits
This is useful in scenarios of creating cache entries where the contents are sensitive to data changes on indices, especially involving a query spanning multiple sites within a Multisite.
This is currently needed on a project to better enhance Block-level caching of HTML, where the block features a number of posts from a number of websites across a Multisite. The underlying
WP_Query
is powered by ElasticPress. Currently for these blocks I am setting a lower cache time - i.e. 15 minutes - to ensure it updates quickly for new content across the sites.For Blocks which are purely
WP_Query
/ database driven, the cache time can be set much higher as I can utilisewp_cache_get_last_changed( 'posts' )
to determine when content updates have occurred. This PR provides a way of doing the same with ElasticPress across multiple sites.The alternative would be to query each site individually to see the latest content updates, however this would negate any meaningful performance benefit of caching the HTML output of the block.
A quick note on posts and ElasticPress last changed cache:
The following lines may appear identical in purpose.
However there is a slight difference:
wp_cache_get_last_changed( 'posts' )
will not update when the index is deleted.Useful Links:
wp_cache_get_last_changed()
- WordPress Code Referencewp_cache_get_last_changed()
in WordPress Core.Possible Drawbacks
None that I can foresee. The change is inconsequential to the general operation of ElasticPress.
Verification Process
Steps:
wp_cache_get_last_changed()
- I use a dirty / hackyvar_dump()
as noted in the code snippet below.wp_cache_get_last_changed( 'elasticpress-network' )
will be identical on both sites,wp_cache_get_last_changed( 'elasticpress' ) )
will be different (as the sites were indexed at separate times).elasticpress-network
.elasticpress-network
.wp elasticpress index --setup --network-wide
in the terminal - both sites will have identical values.Apologies for the dirty / hacky way of checking, but it was simpler than creating a custom block and much easier to explain when you can just see a value on the screen.
Checklist:
Applicable Issues
My apologies, got this far down the PR before realising that there is suppose to be issue created 😬
Changelog Entry