Cache the results of the posts_request_ids query

[ryan]

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

[ryan]

The gist

[ryan]

found_posts caching

[ryan]

Related: #15565

[ryan]

Add context arg to clean_post_cache(). Don't update last_changed for certain contexts.

[nacin]

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.

[ocean90]

#36792 was marked as a duplicate.

[spacedmonkey]

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.

[spacedmonkey]

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.

[DrewAPicture]

@spacedmonkey Looks like we still need some tests here.

[spacedmonkey]

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.

[spacedmonkey]

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.