[wp-trac] [WordPress Trac] #39382: Skipping term cache cleaning when cache invalidation is suspended

[WordPress Trac]

#39382: Skipping term cache cleaning when cache invalidation is suspended
--------------------------+--------------------------------
 Reporter:  zachop        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:  4.3
 Severity:  normal        |  Resolution:
 Keywords:  2nd-opinion   |     Focuses:  docs, performance
--------------------------+--------------------------------
Changes (by boonebgorges):

 * keywords:   => 2nd-opinion


Comment:

 Hi @zachop - Sorry for the delayed response - I missed this ticket when it
 first came in. Thanks for the detailed report, and welcome to WP Trac!

 When you refer to a "term cache" that is "persistent", I assume you mean
 the term hierarchy that WP stores in `wp_options`. Is that correct? If so,
 I disagree that it should be treated differently from the "object cache"
 with respect to suspended invalidation. For one thing, the
 `{$taxonomy}_hierarchy` and `{$taxonomy}_children` caches, like term
 caches fetched by `wp_cache_get()`, are not meant to be directly accessed
 by the developer. From the point of view of the user who's calling
 `get_terms()` or `get_term()` or whatever, the cache implementation is
 totally invisible. Moreover, the distinction between "persistent" caches
 and the object cache largely disappears when running a persistent object
 cache backend like Memcache. For these reasons, I think it's correct that
 `wp_suspend_cache_invalidation()` - which *is* developer-facing - would
 affect both types of caching mechanisms in the same way.

 For these reasons, I agree with you that it's confusing for a function
 like `wp_cache_flush()` not to clear *all* caches. If the distinction
 between `wp_options`-based caching and proper object caching is supposed
 to be invisible to the developer, then `wp_cache_flush()` ought to clear
 both kinds of cache. I think it's worth investigating whether we can come
 up with a comprehensive list of places in WP where we use the database as
 a poor-man's-cache, and then to think about whether we can come up with a
 way of clearing all of these caches with a single method. (This might
 require something like an internal registry of database-cache keys.) It's
 probably impractical to modify `wp_cache_flush()` to handle this kind of
 invalidation, because cache drop-ins redefine this function, and we don't
 have control over them. But we could probably have a new wrapper - maybe
 something like `wp_flush_all_caches()` - that would wrap
 `wp_cache_flush()` and all db caches.

 What do you (and others) think about this idea?

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