[wp-trac] [WordPress Trac] #22176: Cache the results of the posts_request_ids query

[WordPress Trac]

#22176: Cache the results of the posts_request_ids query
-------------------------------------------------+-------------------------
 Reporter:  ryan                                 |       Owner:
                                                 |  spacedmonkey
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.1
Component:  Query                                |     Version:  3.4.2
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion has-unit-      |     Focuses:
  tests early needs-testing needs-dev-note       |  performance
-------------------------------------------------+-------------------------

Comment (by dd32):

 Replying to [comment:28 peterwilsoncc]:
 > A final decision to be made is to decide upon the default setting for
 caching, `post_query_cache`:
 > ...
 > The sticking point of always `true` is that some plugins and/or custom
 WP-CLI commands may be expecting an uncached value.

 The question arrises here - Does the benefit of providing caching outweigh
 the slight potential back-compat breakage? I think it does, and that
 anything expecting uncached data should be specifying the `cache_results`
 flag to bypass it already.

 In my mind - altering the database without going through WordPress APIs
 (which would change the cache key) is something that already results in
 unexpected results, for example, changing a post_status in the DB you then
 need to call (at a minimum) `clean_post_cache( $post_id )` (Which
 updates/cleans the post cache, and bumps the posts last_changed key). That
 means that while there's a chance of BC breakage here, it's far more
 likely that affected code is already broken - although maybe not
 obviously.

 If ultimately the risk-appetite isn't there from the committer(s), I would
 like to suggest an alternative way forward: Conditionally-enabled in X.Y +
 Dev Note, Enabled-by-default in Nightly builds and in X.Y+1 or X.Y+2
 release builds. The reverse of deprecation effectively.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/22176#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform