Opened 9 years ago
Last modified 4 years ago
#22176 new enhancement
Cache the results of the posts_request_ids query
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 3.4.2 |
Component: | Query | Keywords: | has-patch 2nd-opinion has-unit-tests |
Focuses: | performance | Cc: |
Description (last modified by )
We are to the point where we could replace the advanced post cache plugin with something in core that is far simpler. We're most of the way there since introducing the split query. And with #22024 we have a good way of doing per-blog cache invalidation for classes of objects, which would be needed by this. Leveraging wp_cache_get_multi() as suggested in #22174 would provide a complete replacement for the adv post cache plugin. http://plugins.svn.wordpress.org/advanced-caching/trunk/advanced-caching.php
Attachments (7)
Change History (23)
@
8 years ago
Add context arg to clean_post_cache(). Don't update last_changed for certain contexts.
#6
@
8 years ago
A parent deletion could hypothetically change a query that is based on post_parent, or eventual post_parent_in / not_in, child_of, exclude_tree query variables.
This ticket was mentioned in Slack in #core-customize by ocean90. View the logs.
5 years ago
#12
@
4 years ago
- Keywords needs-unit-tests 2nd-opinion added; needs-refresh removed
I have spent sometime on this ticket as I think it is much simpler that originally thought.
- The cache key generated has the post types array. The idea behind this is when new post types are registered caches are cleared.
- The fields element is removed, so that all formats are wp query are stored in the same cache as a list of ids.
- The return points from id and id=>parent formats have been changed. This makes code a little cleaner. It also means that all the filters are fired more, making this code much more hackable.
- I have reused the cache_filter param and changed what it is used for. I believe this is a nice solution.
- Added a param update_post_cache, bring query class into line with other newer query classes like wp_site_query.
I am worried about how filters effect this code. This code has tonnes of filters, any of which may break the caching. Currently none of the core tests are failing.
#13
@
4 years ago
After talking to @boonebgorges about this ticket, I have updated it.
Key changes.
- Now it obeys the posts_pre_query filter
- If tax_query is set, salt the cache key with term last changed.
- Cache key is now generated from the sql string. This is because of the filters on the sql string.
I think will need to look into #40669 to make sure post meta query run correctly.
#15
@
4 years ago
- Keywords has-unit-tests added; needs-unit-tests removed
22176.4.diff Adds unit tests.
Other changes include
- Cache generation is outside of if statement as cache key is used in other parts of code.
- The posts cache group is invalidated when meta data is added/deleted/updated. See #40669
- Cache key is salted with last changed of group terms. This helps invalidation of taxonomy queries.
#16
@
4 years ago
My last patch is going a little bit out of scope. It become about refactoring WP_Query to make the code cleaner. In #41678 does much of the refactoring in this ticket and makes different return types run through filters. As more the filters run on more return types, this caching can happen outside of core.
The gist