Proposal: Add `label` argument to `register_meta` function

[santosguillamot]

With the introduction of Block Bindings, it is more common to see workflows where users need to see the custom fields that are available or connected. Right now, they are relying on the meta key, however, it has been reported many times that it feels too technical.

I propose adding a label argument that can be passed to register_meta that serves as a human-readble name for the meta fields.

Some examples of how it can improved the user experience can be found in this pull request: ​https://github.com/WordPress/gutenberg/pull/65099

With the introduction of Block Bindings, it is more common to see workflows where users need to see the custom fields that are available or connected. Right now, they are relying on the meta key, however, as reported ​here, it feels too technical sometimes.

In this pull request I'm exploring the possibility of adding a new label argument to include a human-readable name that can be used across the UI.

Trac ticket: https://core.trac.wordpress.org/ticket/61998.

I have created the Trac ticket: https://core.trac.wordpress.org/ticket/61998#ticket.

I'm marking this as "Ready for review" because the code is supposed to be ready.

Let's add unit tests to confirm that title from Schema is exposed via the OPTIONS request.

Here's how I did it for settings - ​https://github.com/WordPress/wordpress-develop/pull/6495/files#diff-af62c99b4a5814e31ddbe08c227ee5d547f97f560fe61d26f42bf58beadc6a79.

P.S. I think we can land this without associated Gutenberg enhancement.

I have added a ​unit test for title based on the existing one for default. I wasn't sure if they should be unified or it is okay this way. Just let me know 🙂

P.S. I think we can land this without associated Gutenberg enhancement.

I agree they can be handled separated. Now the Gutenberg PR has its own filter to manage it.

[Mamaduka]

Tentatively adding this to the WP 6.7 milestone.

cc @peterwilsoncc, @kirasong

This pull request is built on top of ​https://github.com/WordPress/wordpress-develop/pull/7298

As suggested by @gziolo ​here, in this pull request I'm exploring the possibility of setting the show_in_rest argument to true by default when the new potential label argument is defined. With the introduction of a new human-readable argument, which hasn't been used before, it could make sense to expose it automatically in the REST API.

Basically, these are the use cases:

• If show_in_rest is defined, that value is always respected.
• No label and no show_in_rest: It keeps working as before and uses show_in_rest false, which is the default. This is a pretty common use case right now.
• Defined label and no show_in_rest: It sets show_in_rest to false. This would be the change introduced.

It seems I can't compare against my other branch. The relevant code changes in this PR are:

• New conditional to change show_in_rest: ​link.
• Add a new unit test to cover this use case: ​link.

Trac ticket: https://core.trac.wordpress.org/ticket/61998

[gziolo]

@Mamaduka, you were 32 seconds faster than me. I'll remove commit and put dev-feedback to ensure WP 6.7 release squad doesn't miss it.

Same here; I left one nitpick in the test file.

I just pushed your suggestion 🙂

There is also this question for integration with REST API of whether label is a strong enough indicator to automatically expose it in the endpoint and change the show_in_rest to true if no value is provided.

I've started a separate pull request to discuss the potential implementation of this: ​https://github.com/WordPress/wordpress-develop/pull/7302

This probably needs a separate track ticket. Similar discussions usually happen there.

I left one minor note. I'm in favor of that enhancement as it is the feedback we get several times from folks using Block Bindings that they need to remember to enable show_in_rest, but I'm happy to hear about potential consequences that make it a bad idea. I can't think of any as of today.

This probably needs a separate track ticket. Similar discussions usually happen there.

I've opened a separate ticket for this: https://core.trac.wordpress.org/ticket/62000#ticket.

I'm pretty strongly against this. Exposing a meta value can be a pretty big footgun. I don't see a compelling reason why we should make that footgun less obvious by conflating the "label" field with whether the meta value is exposed.

I'm sympathetic to the fact that it's easy to forget to enable show_in_rest in lots of situations, but I agree with @TimothyBJacobs. As described in #7298, the purpose of the label is to have "a human-readable name that can be used across the UI" (which is great!). As a developer, I would have no expectation that taking advantage of that enhancement would potentially affect whether data is exposed to the outside world. Even setting a post type to public doesn't automatically enable show_in_rest, and that seems like as strong an indicator as could have been. So, for me, this would be an unwelcome surprise.

Thank you for the feedback shared so far. I'm not surprised as it indeed could be confusing to learn that label has some special behavior when registering a new meta. It looks like what could help is having something at the level of abstraction that WP_REST_Meta_Fields is. In essence, is there a way we could allow registering a meta field, that with some new set of properties could get easily integrated into the editor and new concepts like Block Bindings, Data Views, exposed in the sidebar of the editor when editing the post type, etc. I guess the Fields API project is partially related to that but in other areas of WP Admin.

is there a way we could allow registering a meta field, that with some new set of properties could get easily integrated into the editor and new concepts like Block Bindings, Data Views, exposed in the sidebar of the editor when editing the post type, etc

Isn't that what register_meta_field and the REST API does? What am I missing?

Isn't that what register_meta_field and the REST API does? What am I missing?

There is no function register_meta_field, so I assume you are referring to how the REST API works for Post Meta. At some point, we will have to revisit it and introduce some more high level utility that while registering post meta field is able to autoamtically expose it through REST API, create a block variations with ease for existing blocks with bindings applied, etc.

Anyway, I'm closing this PR for now. Thank you all for valuable feedback.

I think @TimothyBJacobs was referring to the ​`register_rest_field` method.

[gziolo]

In 59023:

Meta: Add label argument to register_meta function

With the introduction of Block Bindings, it became more common to see workflows where users need to see the custom fields that are available or connected. They were relying on the meta key, however it feelt too technical sometimes. The solution is adding a new label argument to include a human-readable name that can be used across the UI.

Props santosguillamot, mamaduka, gziolo, timothyblynjacobs, peterwilsoncc.
Fixes #61998.

@SantosGuillamot, thank you for addressing the remaining feedback. I committed the changes with https://core.trac.wordpress.org/changeset/59023.