[wp-trac] [WordPress Trac] #19690: wp_suspend_cache_additions() doesn't block term_relationships being added to cache

WordPress Trac wp-trac at lists.automattic.com
Sat Apr 7 11:01:14 UTC 2012


#19690: wp_suspend_cache_additions() doesn't block term_relationships being added
to cache
--------------------------+-----------------------
 Reporter:  leewillis77   |       Owner:  ryan
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  3.4
Component:  Cache         |     Version:  3.3
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+-----------------------
Changes (by duck_):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Replying to [comment:15 ryan]:
 > In [19729]:
 > {{{
 > #!CommitTicketReference repository="" revision="19729"
 > Use wp_cache_add() instead of wp_cache_set() when priming the object
 term cache in update_object_term_cache(). Pass the real post_type to
 clean_object_term_cache() instead of hard-coding post. Call
 clean_object_term_cache() from clean_bookmark_cache(). Props leewillis77.
 fixes #19690
 > }}}

 This causes a notice in clean_post_cache() when it's called from
 wp_delete_post() and the post being deleted isn't in the cache. This is
 because get_post() will not return an object as the post no longer exists.

 {{{
 PHP Notice:  Trying to get property of non-object in wp-includes/post.php
 on line 4368
 }}}

 This is quite hard to reproduce under normal conditions as it is often
 masked by the post being in the cache at the get_post() call. Artificial
 reproduction is easy by calling `wp_suspend_cache_addition( true )` before
 wp_delete_post(). It also causes an error in the unit tests when WP_DEBUG
 is enabled.

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


More information about the wp-trac mailing list