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

WordPress Trac noreply at wordpress.org
Thu Jul 14 23:23:35 UTC 2016


#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):

 [attachment:35658.47.diff] is a new iteration after the
 [https://make.wordpress.org/core/2016/07/14/register_meta-discussion-
 recap-july-14-2016/ discussion] today.

 **Highlights:**

 The word "subtype" has basically been eliminated thanks to CURIE syntax.
 :heart:

 I ''think'' we're able to maintain back-compat filters and have the new
 filters by just using `$object_type` and not worrying about logic to
 separate them.

 The CURIE string flows pretty well through all existing `_metadata()`
 functions, though we do need to strip it down to find the table and column
 names. This is very light weight.

 Tests are still passing.

 **We shoulds:**

 I think we should ditch `wp_object_type_exists()` and just allow things to
 work as they do with good documentation on expectations. /cc @helen

 While the CURIE string flows well, several actions will end up changing to
 `actionname_post:post_etc` by default without stricter stripping of the
 second piece. I *think* this is okay, but more thought is needed.

 Also, to retrieve individual registered meta for a custom post type, a
 developer would need to use `get_metadata( 'post:books', .... )` instead
 of `get_post_meta()` *unless* we add another parameter for subtype to
 `get_post_meta()`.

 Revisit the error messages and return values. I may agree with @rmccue in
 #37345 that `doing_it_wrong()` is better here, though I do like having
 `WP_Error` to test against. (Can we test a doing it wrong?)

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


More information about the wp-trac mailing list