[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