[wp-trac] [WordPress Trac] #52710: Taxonomy: Make it possible to bypass automatic caching of results in `get_terms()`

[WordPress Trac]

#52710: Taxonomy: Make it possible to bypass automatic caching of results in
`get_terms()`
-------------------------+-----------------------------
 Reporter:  dlh          |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Taxonomy     |    Version:  2.3
 Severity:  normal       |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 With a few exceptions, every call to `get_terms()` places the query
 results in the object cache for 24 hours as part of
 `WP_Term_Query::get_terms()`. The query results are cached under a key
 that is based on the `last_changed` cache value for the `terms` cache
 group, such that whenever `last_changed` changes, all cache entries become
 stale.

 Many different events can bump the `last_changed` time for terms,
 including creating, updating, or deleting terms, or changing the terms
 assigned to a post.

 For busy sites (even not-so-busy ones), these events happen many times a
 day, if not many times an hour. The chances of any cached term results
 surviving for 24 hours without being made stale is basically zero.

 For sites that are behind a full-page HTML cache, the chances of a request
 reaching WordPress such that the cached term results can be reused before
 they're made stale are also somewhat small.

 Lastly, larger sites are likely to have implemented their own query
 caching in ways that are optimized for their use cases and that make
 core's caching redundant.

 For these sites, the result is a heap of unreachable cache entries waiting
 to expire or be evicted. The goal of this ticket is to give developers a
 way to prevent the caching from occurring.

 The attached patch proposes a boolean `update_get_terms_cache` parameter
 for `get_terms()` and `WP_Term_Query::get_terms()` (so named for the cache
 key prefix). When `false`, caching is skipped. The parameter can be set on
 a per-query basis or made `false` by default via the `get_terms_defaults`
 filter.

 That's one idea, and I'm open to any others that might gain a consensus.
 For example, the cache TTL could be made into a parameter. So could the
 `cache_group`, allowing developers to direct the results into a non-
 persistent group.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52710>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform