alleyinteractive
Consider support for register_meta()
WordPress 4.6 introduces a fundamental change to the way meta fields are registered. The primary change is the addition of meta metadata such as its type, description, value structure, and whether to expose it in the REST API.
It should be considered whether registered Fieldmanager meta fields should also call register_meta() in order to expose meta fields to this new meta API.
This is actually in progress. Contributions welcome!
https://github.com/alleyinteractive/wordpress-fieldmanager/tree/rest_api
@joemcgill Any chance of adding register_meta support to fields? Adding show_in_rest support would be great!
Hey @spacedmonkey! Sorry for the lack of updates and transparency on this. We've hemmed and hawed over this for years and have deliberately not acted on it one way or another, pretty much, waiting for a stiff breeze from any direction. I'd be interested to hear more about your use case, maybe you've encountered a situation we haven't.
Here's the explanation for why we haven't ever acted on it:
An unwritten rule we try to adhere to with Fieldmanager is that it can be removed from a site and any data created with Fieldmanager would persist and keep working. We think of Fieldmanager as a code-level API for creating admin interfaces for underlying WordPress core functionality, and Fieldmanager does not add any functionality itself. A happy consequence of that is that Fieldmanager doesn’t lock you into using Fieldmanager. As a very real example, one could replace a Fieldmanager field with a Gutenberg block/plugin/slotfill/etc. and it requires no additional work beyond creating that interface for Gutenberg.
If Fieldmanager is exposing fields to the REST API, then deactivating Fieldmanager could have some very unexpected and unintended effects. It could break something else completely unrelated, for instance a mobile app expecting some data to be in the API. This prompts a discussion of separation of concerns. Registering meta can be argued at face value to be something that should be Fieldmanager’s responsibility. My general opinion is that it’s not, since Fieldmanager is auxiliary to the data with which it interacts. Fieldmanager doesn’t need meta to be registered and doesn't use the underlying data in any way except to load it into an interface. I would therefore argue that the act of registering meta should be the responsibility of whatever code wants to use it, be it a theme or a plugin or what have you. Personally, when I'm creating my data structures (e.g. custom post types), I like to have a model that owns its meta. That model handles the Fieldmanager field registration, as well as the meta registration if applicable, or perhaps WPGraphQL fields registration if the site is using that. Here's an example of that (this example is using WPGraphQL and our framework Mantle, but even if both are foreign to you, you'll get the gist of how concerns are organized here and how the model is owning the data, merely leveraging Fieldmanager to create the interface).
