[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           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 See #40669, r41848, r41849.

 Sorry, but I completely missed this work being done for the 4.9 release
 cycle.

 I think the individual post/comment/term/user checks should be moved
 directly into the appropriate meta API function calls.

 I can imagine 2 ways of doing this:

 ----

 Add a `$cache_key` parameter to the following functions:

 * `add_metadata()`
 * `update_metadata()`
 * `delete_metadata()`

 When `$cache_key` is not empty, it will internally call:

 `wp_cache_set( 'last_changed', microtime(), $cache_key );`

 ----

 Infer the cache-key using `$meta_type` in the following function:

 * `update_meta_cache()`

 Then call:

 `wp_cache_set( 'last_changed', microtime(), $meta_type . 's' );`

 (We already use `$meta_type` to infer things like primary keys, so it's
 not great, but not new.

 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...)

 cc @boonebgorges @spacedmonkey for consult & discussion

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