[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 boonebgorges):

 > Infer the cache-key using $meta_type in the following function

 I like this for its simplicity, but I'm concerned about third-party uses
 of `update_metadata()`. This change would mean that we're setting
 `last_changed` for any object type `foo` that may be passed in. More
 conservatively, we could work from a whitelist:

 {{{
 // meta_type => cache_group
 $cache_groups = array(
     'post'    => 'posts',
     'comment' => 'comments',
     // etc
 );

 if ( isset( $cache_groups[ $meta_type ] ) ) {
     wp_cache_set( 'last_changed', microtime(), $cache_groups[ $meta_type ]
 );
 }
 }}}

 Of course, it could be that I'm too conservative 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()`. We could probably look through the plugin repo and
 maybe do some other environment scans to see if this is a real concern. If
 not, I think something like the above could be modified to:

 {{{
 $cache_group = isset( $cache_groups[ $meta_type ] ) ? $cache_groups[
 $meta_type ] : $meta_type;
 wp_cache_set( ... );
 }}}

 (rather than mucking about with `'s'`)

 > If we went this route, I believe we'd probably want to do a better job
 of priming meta-data caches the same way we prime primary object caches
 (users and posts specifically prime themselves on update, etc...)

 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?

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