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

WordPress Trac noreply at wordpress.org
Sun Jun 26 23:18:19 UTC 2016


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

Comment (by jeremyfelt):

 There were several conversations around `register_meta()` during WordCamp
 Europe this weekend and the general consensus is that we should get
 something simple in now that provides a good option for future
 compatibility. /cc @helen @rmccue @danielbachhuber @ericlewis @joehoyle

 I refreshed the initial patch as [attachment:35658.4.diff] with this in
 mind. As we have only a handful of days left before beta 1, immediate
 feedback is helpful. :)

 After re-reading the entire thread, I want to reword some assertions from
 a previous [comment:15 comment] that I think still apply, but without REST
 API specific language:

 1. Meta is either protected or not protected via the application of an
 auth callback or with a _ prefix.
 2. Both protected and not protected meta should be registered with
 whitelisted arguments.

 In the latest patch, the whitelisted arguments are:

 * `sanitize_callback`
 * `auth_callback`
 * `object_subtype` (only accepted when object type is "post")
 * `type`
 * `description`
 * `show_in_rest`

 Using `show_in_rest` rather than a more generic `public` allows us to
 start solve an immediate problem at hand while not falling into the trap
 of defining one version of "public" that may get less clear in the future.
 (See `register_post_type()`).

 `type` and `description` should not necessarily be limited by core. The
 REST API (and others) can determine what is valid for that specific use.

 Thank you @ericlewis and @sc0ttkclark for exploring the possibilities in
 the several other patches (!!!) on this ticket. I think this work will
 continue to guide where we need to go.

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


More information about the wp-trac mailing list