[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