Proposal: Set `show_in_rest` to `true` by default when label argument is defined

[santosguillamot]

If this other ticket to add a label argument goes forward, it opens 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.

While working on block bindings, part of the feedback received is that people need to remember to set show_in_rest to true.

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 true. This would be the change introduced.

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 true. 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/62000

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.

[poena]

Hi
Can you please add a reference to what this refers to?

If this other ticket to add a label argument goes forward

Such as a link to an existing Trac ticket.

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.