[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:
-------------------------------------------------+-------------------------

Comment (by tharsheblows):

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

 Currently it does and you're right, I think the verdict was that it wasn't
 safe to include. Should `register_meta()` error if `show_in_rest` is true
 and the data fails the serialization check?

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

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

 I had imagined authorization for the REST API would be handled by the REST
 API as it only affects the edit context and the create/ update/ delete
 permissions as you said and not the public contexts. Authorization would
 either go as the custom callback if there is one or the user's
 add/edit/delete capabilities with respect to the parent if there's not.

 And yes, I think `show_in_rest` is enough as it's explicit, consistent
 with `register_post_type` and opt-in.

 There could be the case where a protected meta key has `show_in_rest =>
 true`. In that case, which has priority? I would guess `show_in_rest` but
 don't know -- how does the Fields API deal with protected meta keys?

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