[wp-trac] [WordPress Trac] #43813: Meta API should set `last_changed` cache key internally

[WordPress Trac]

#43813: Meta API should set `last_changed` cache key internally
-----------------------------+------------------------------
 Reporter:  johnjamesjacoby  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by johnjamesjacoby):

 > I'm not sure I understand. Are there specific places where we're not
 doing a good job of this? How does the refactoring of how the last_changed
 incrementor gets bumped - the subject of this ticket - affect the priming
 of metadata caches?

 Sorry; I was implying/speculating there may be more here, because meta
 caches are primed opposite of the `last_changed` key.

 For example, when using the meta-data API directly (not the per-object
 helpers) calls to `update_meta_cache()` happen inversely to when the
 `last_changed` cache key gets updated. It's hard to tell (without testing
 for the condition) but looks like it's possible for an "updated meta
 cache" to have an out of date `last_changed` key.

 That makes me think, the meta-data API could use a way to relate meta
 cache-groups to object cache-groups, like you mentioned. If we need that,
 maybe this turns into a bigger, different issue. Would be nice if that
 whitelist had a filter, so plugins can just add their relationship to it.

 (Separately, BuddyPress doesn't appear to update any `last_changed` keys,
 so while our meta-cache implementation is improved over WordPress core, it
 probably needs the same treatment WordPress needs here.)

 > The only real harm that could be caused if WP set last_changed for
 arbitrary cache groups is if those plugins were expecting last_changed to
 be in a format other than microtime()

 A helper function like `wp_cache_set_last_changed()` would help there, so
 there is some functional format enforcement in core.

 See: https://core.trac.wordpress.org/ticket/37464#comment:17

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