[wp-trac] [WordPress Trac] #22223: Potential for post cache corruption since r21735

[WordPress Trac]

#22223: Potential for post cache corruption since r21735
--------------------------+------------------
 Reporter:  ryan          |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.5
Component:  Cache         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+------------------

Comment (by ryan):

 Replying to [comment:5 ryan]:
 > However, if both cache_results and split_the_query in
 WP_Query::get_posts() are false then the posts won't be added to the cache
 if get_post() doesn't wp_cache_add(). An environment using a persistent
 cache backend and a plugin such as advanced post cache that hasn't been
 updated to work with the split query would fit this scenario (cough,
 wordpress.com).

 This would be good, in part, because it would restore the 3.4 intent
 behind cache_results = false because get_post() in the array_map() would
 no longer be going behind its back and doing a bunch of wp_cache_add()
 calls anyway.  But that would leave get_post() by post ID as the only way
 to get posts into cache. I suspect that passing objects to get_post()
 while rolling through The Loop is the main way posts are added to cache
 when cache_results = false, however.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22223#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software