Create a Generic Control to edit post meta data

[bobbingwide]

In March, while developing the SB theme, for s.b/bigram I developed logic to deal with the _seen_before post meta field in the bigram plugin.

• The _seen_before field is registered using bigram_register_post_meta which calls register_post_meta.
• This is called from bigram_register_seen_before, in bigram_oik_fields_loaded which is the action hook for oik_fields_loaded.
• The plugin provides the bigram/seen-before block that pretty much duplicates the logic documented in https://developer.wordpress.org/block-editor/how-to-guides/metabox/meta-block-3-add/
• This code works.

When using the REST request http://s.b/bigram/wp-json/wp/v2/bigram the meta field is correctly populated.

In s.b/wordpress I'm using a different method to register the post meta fields. They don't show up in meta. Why not?

[bobbingwide]

But they don't show up in meta. Why not?

Explanation

This is a documented pre-requisite; the post type needs to support custom-fields. See https://developer.wordpress.org/block-editor/how-to-guides/metabox/meta-block-2-register-meta/

For bigram, I'd already changed the post type registration. See https://github.com/bobbingwide/bigram/issues/23#issuecomment-808876903

The CPTs registered by oik-plugins did not support custom fields. Once changed the meta data appeared in the REST responses.

[bobbingwide]

Having resolved the problem of not being able to access the post meta data I've got to the point where I can display a plain text value and even attempt to change it. Here we see the value of the Plugin slug ( field oikp_slug ).

If I change the value of the post meta field in the Field block then the value does get updated in the meta data for the REST POST request.

https://s.b/wordpress/wp-json/wp/v2/oik-plugins/13321?_locale=user

But in the subsequent request the metabox update overrides the change in the block.

https://s.b/wordpress/wp-admin/post.php?post=13321&action=edit&meta-box-loader=1&meta-box-loader-nonce=5fc9a76965&_locale=user

So how do we synchronize the values between the block and the meta box and/or prevent the metabox update from changing the value back to the original setting?

[bobbingwide]

So how do we synchronize the values between the block and the meta box and/or prevent the metabox update from changing the value back to the original setting?

I can use Options > Preferences > Panels to toggle off the display of the Fields meta box.

But this doesn't prevent the meta box from submitting its values, which have not been changed.

Somewhere I read about the fact that updating the meta data doesn't cause the Update button to be set. And the author had implemented a hack to force this to happen. Maybe someone's also written some docs on how to update fields in meta boxes? Yoast SEO does it with Panels

[bobbingwide]

OK, so I'm not the only person with this problem. Gutenberg issue 23078 is over a year old, so even though the bug was triaged yesterday, I imagine the chance of a solution being developed in the next couple of weeks appears to be very low.

A workaround for the problem was documented against another issue that was closed as a duplicate of 23078. https://github.com/WordPress/gutenberg/issues/23304#issuecomment-874484723 I'll have to try the workaround ( Disable the Custom Fields) meta box, when I've re-enabled the field edit capability.

Solving this problem is just the first of many challenges of replacing Meta boxes with blocks.

1. Without Meta boxes how do we ensure that each of the mandatory post meta fields are given values?
2. How will the user interface appear? How will the user find the blocks they should complete?
3. How do we prevent the user from removing blocks required to set mandatory fields?
4. And how best cater for multiple values?
5. What about conditional fields? Not a problem for me, but would be for ACF users.