[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:  helen
     Type:  task (blessed)                       |      Status:  accepted
 Priority:  high                                 |   Milestone:  4.6
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests needs-testing has-  |     Focuses:
  patch rest-api needs-dev-note                  |
-------------------------------------------------+-------------------------

Comment (by jeremyfelt):

 Naming things is tough. :) CURIE makes sense (IMO) to describe
 'string:string', but we should probably stick to "colon delimited string".

 That aside, @rmccue had some good feedback in Slack earlier today that
 kept the wheels turning away from colon delimited strings. /cc
 @danielbachhuber

 One of the first [comment:2 comments] on this ticket (me), stressed the
 importance of uniqueness based on our discussion at A Day of REST. It's
 worth rethinking the importance of this uniqueness.

 I'm using the REST API here as it's our best example of how this will be
 used.

 If one developer registers a meta key of `rating` for a custom post type
 and sets `show_in_rest` to `false` and another developer registers a meta
 key of `rating` for another custom post type and sets `show_in_rest` to
 `true`, does this conflict matter?

 In the current defensive approach, it does matter. Private information is
 not accidentally exposed as public in an endpoint.

 However, we do have situations like this throughout core where conflicting
 slugs or key names can cause problems. We don't always solve for every
 possibility.

 In another approach, the onus is on the developer to choose a unique key
 name, especially for private data. This would allow us to skip all of the
 subtype handling and just start handling registered meta without adjusting
 filters or the function signatures of many `_meta*()` functions.

 Thoughts?

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