New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADOR '16 Hack Day - Meta Team #2149

Closed
jeremyfelt opened this Issue Jan 29, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@jeremyfelt
Contributor

jeremyfelt commented Jan 29, 2016

We discussed how to approach the implementation of post, comment, term, and user meta in the REST API and came up with a few areas to focus on.

How to determine if meta is public

WordPress core currently contains the concepts of protected and authenticated meta. These may be useful to us when determining what to publicly expose in the REST API.

  • If the first character of a meta key is _, meta is considered protected.
  • If an auth callback is provided, meta passes through that auth callback, though isn't necessarily treated as protected.
  • If the first character of a meta key is not _ and no auth callback is provided, meta is treated as public.
  • There is also an is_protected_meta filter to override is_protected_meta().

Using register_meta() doesn't seem to be common among developers, so it's hard to rely on the current "publicness" of the meta. It's possible that we can treat meta as public in its current state. It's also possible that we'll need to add a specific argument for registering meta as public rather than as its default of unprotected. If we do add a specific argument, this may be show_in_rest to mirror register_content_type().

A piece to keep in mind is the existence of the_meta() (since 1.2.0), which can be used by a theme to output all currently unprotected meta in a list.

  • Action: Search plugin directory to determine how register_meta() is currently being used.
  • Action: Search plugin/theme directory to determine if/how the_meta() is currently being used.

Enhancing register_meta()

We determined that it would be useful to expand the scope of register_meta() a bit so that specific information about that meta data could be registered, similar to register_content_type().

This information should probably include the expected data type (string, int, etc...) and the description so that a more proper JSON Schema for the endpoint could be provided.

If it's determined that we need a more explicit way of registering the publicness of meta, this could be provided as well.

Any enhancements to register_meta() are beneficial to core as a whole and not entirely REST API specific, though type and description will help directly.

  • Action: Open a core ticket to discuss enhancements to register_meta().
  • Action: What other data should be provided with register_meta()?

How to expose meta in the API

Once we can determine the publicness of meta, we should be able to query for all of the public meta in a way that can be attached to an endpoint automatically. As mentioned before, the_meta() is available for themes to output a list of all unprotected meta. There is likely room for get_registered_meta(), which would not only return all of the public meta key/values, but also the meta for the meta—data type, description, etc... so that it can be reliably used via the API.

Ideally, for meta to appear in an endpoint, it should be registered so that the proper metadata for that meta can be provided.

Related tickets: #1425 (Primary), #1129, #1144.

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Jan 29, 2016

Contributor

Core ticket for registering meta meta: https://core.trac.wordpress.org/ticket/35658

Contributor

jeremyfelt commented Jan 29, 2016

Core ticket for registering meta meta: https://core.trac.wordpress.org/ticket/35658

@martingoldie

This comment has been minimized.

Show comment
Hide comment
@martingoldie

martingoldie Jan 29, 2016

Possible correction. When you say:

register_content_type()

Do you actually mean register_post_type() as I could not find a function named register_content_type()?

martingoldie commented Jan 29, 2016

Possible correction. When you say:

register_content_type()

Do you actually mean register_post_type() as I could not find a function named register_content_type()?

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Jan 29, 2016

Contributor

Oops, it is register_post_type(). I've always wanted it to be the other. :)

Contributor

jeremyfelt commented Jan 29, 2016

Oops, it is register_post_type(). I've always wanted it to be the other. :)

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber
Member

danielbachhuber commented Mar 14, 2016

Let's continue this conversation in https://core.trac.wordpress.org/ticket/35658

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment