[wp-trac] [WordPress Trac] #35658: Provide additional data for registered meta through register_meta()

[WordPress Trac]

#35658: Provide additional data for registered meta through register_meta()
-------------------------------------------------+-------------------------
 Reporter:  jeremyfelt                           |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Options, Meta APIs                   |  Review
 Severity:  normal                               |     Version:
 Keywords:  needs-unit-tests needs-testing has-  |  Resolution:
  patch                                          |     Focuses:
-------------------------------------------------+-------------------------
Changes (by jeremyfelt):

 * keywords:  needs-patch needs-unit-tests => needs-unit-tests needs-testing
     has-patch


Comment:

 Rabbit. Hole. :)

 [attachment:35658.diff] is an initial exploration, combining the thoughts
 (I think) so far:

 * `register_meta()` now supports an array of arguments as the 3rd
 parameter rather than individual parameters for `$sanitize_callback` and
 `$auth_callback`.
 * New arguments for `register_meta()` include `object_subtype`,
 `show_in_rest`, `type` (data type), `description`.
 * `register_meta()` now actually registers meta keys in the global
 `$wp_meta_keys`, similar to post types, so that data about the meta keys
 can be retrieved separately from the values associated with those keys.
 * Introduce `unregister_meta_key()` as a way to remove a previously
 registered meta key. Also similar to `unregister_post_type()`.
 * Introduce `get_registered_meta_keys()` to provide a list of registered
 meta keys for an object type and subtype.
 * Introduce `get_registered_metadata()`, effectively as a wrapper for
 `get_metadata()` that returns only data associated with registered meta
 keys for a given object ID and type.
 * Update `sanitize_meta()` to support an `$object_subtype` parameter.
 * Update `sanitize_meta()` to apply a new
 `sanitize_{$object_type}_{$object_subtype}_meta_{$meta_key` filter for
 sanitization.
 * Change the `$meta_type` parameter to `$object_type` in `sanitize_meta()`
 to better match `$object_subtype`.
 * Some initial tests.

 REST API hack day contributors to the discussion that kicked this patch
 off: @tharsheblows, @nullvariable, @ivdimova, @kvignos, @akibjorklund,
 @martingoldie, @potatomaster, @jaredcobb

 Some thoughts during patch creation:

 * Do we need to validate object types during `register_meta()` so that
 this doesn't accidentally become something it's not? Or do we already
 provide accidental support for different object types at this point AND
 want to provide an enhanced structure for that as well?
 * Once you have an object ID, the subtype of the object no longer matters
 as much, only as a way to verify that the meta key has been registered for
 that subtype. So we don't necessarily need to convert all existing filters
 around meta to handle subtypes (immediately at least), only the ones that
 do not support an object ID.
 * Is it overkill to add all of the handling for subtypes to every type of
 object? Would it be more overkill to split the logic up into object types
 that support subtypes? It's probably safe to handle objects as if they
 could be split into types and subtypes.
 * More rabbit holes appear when you start to dig into how to handle
 serialized data. This is something we can't support fully in the REST API,
 but is something that is used elsewhere. Could it make sense to say that
 registered metadata cannot be serialized? If we do that, do we then need
 to enforce it whenever storing meta as well? I guess this is more of a
 problem at the REST API layer, which could feasibly check for
 `is_serialized()` and avoid providing bad data.
 * It's possible `show_in_rest` isn't a good name. It may be enough to
 explicitly register as `public` rather than the current behavior, which is
 registering as not protected.
 * The filter applied for sanitization is straight forward as it is applied
 for all object types (meta types). The auth callback is only applied for
 the `post` object type, so does not currently fire for `user`, `comment`,
 or `term`. It may make sense to expand this, but it may also be an
 opportunity to revisit how authorization works around meta. /shrug
 * Adding to that, authentication is only checked when saving or editing
 post meta and not for reading post meta. Is something like `show_in_rest`
 enough? If meta is registered as public through `register_meta()`, should
 we assume that its publicness then matches that of the parent object at
 that point? Probably.
 * Should a post type (or object subtype) exist before a meta key can be
 registered to it? That could cause confusion depending on the timing of
 registration. It may not hurt anything if registered out of order.

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