Meta Boxes: Add an action for plugins to print hidden inputs in the meta box form

[pento]

Some plugins require extra hidden fields to be POSTed to the server when meta boxes are saved.

Historically, these hidden fields have been hooked all over the place. For example, ACF uses the edit_form_after_title action.

To consolidate these in the block editor, a new action needs to fire when the meta box form is being printed.

[pento]

45283.diff​ adds the block_editor_meta_box_hidden_fields action.

In the case of ACF, to continue the example, this action would be used by adding the following line to ACF_Form_Post::initialize():

add_action( 'block_editor_meta_box_hidden_fields', array( $this, 'edit_form_after_title' ) );

[danielbachhuber]

Related ​https://github.com/WordPress/gutenberg/issues/10929

[pento]

45283.2.diff​ is based on @danielbachhuber's suggesting in GB10929, to capture the output from these filters that some plugins use to output hidden input fields.

It also adds filtering to only allow hidden input fields, so other output can be accidentally dumped into the form.

ACF works correctly, with no modification, with this patch.

@danielbachhuber: What do you think of this direction?

[pento]

It's likely that edit_form_after_title and edit_form_advanced could both be run after admin-header.php, in which case we don't need to pass them around like this. We can run the actions in the_block_editor_meta_box_post_form_hidden_fields() and output the hidden fields there.

[danielbachhuber]

@pento I don't love using output buffering and regex as a shim, but it does give us whitelist control over the behavior. I notice that core itself has this, which we wouldn't want to accidentally render:

// Show a "postbox" with the text suggestions for a privacy policy.
add_action( 'edit_form_after_title', array( 'WP_Privacy_Policy_Content', 'notice' ) );

It's likely that edit_form_after_title and edit_form_advanced could both be run after admin-header.php, in which case we don't need to pass them around like this.

Do you think this runs the risk of any execution order bugs?

[pento]

Yeah, that's why it does the wp_html_split(), which reliably breaks everything up into an array of HTML nodes, then we can do simple checks to ensure we're only getting the hidden input fields.

Do you think this runs the risk of any execution order bugs?

I don't think so, given that they're both run after admin-header.php in edit-form-advanced.php. It seems like this would give us more reliable output than the current method.

I'm pondering how we should mark this practice as not recommended, though. Maybe do_action_deprecated(), though I'm not sure if we've ever marked an action as deprecated in a certain context, but not deprecated in others.

[pento]

In 43882:

Meta Boxes: Add the block_editor_meta_box_hidden_fields action.

Lacking an appropriate action in the classic editor, plugins that add meta boxes have historically hooked into various actions in order to add hidden input fields.

This change also adds backwards compatibility for two of the most common: edit_form_after_title, and edit_form_advanced.

Props pento, danielbachhuber.
See #45283.

[elliotcondon]

Good work adding in support for the edit_form_after_title action.

Can we consider removing the "input only" restrictions here and allow plugins (like ACF) to output more than hidden input fields?

ACF uses this action to render another metabox area ("acf_after_title"), a <style id="acf-style"> element and also a <div id="acf-form-data> element surrounding the input fields.

If this restriction is in place to prevent a potential error in 3rd party code, may I make an alternative suggestion:

Instead of calling the edit_form_after_title and edit_form_advanced actions within the .metabox-base-form element, consider calling them later in a separate visible wrapping form element. For example: <form id="classic-actions" class="classic-js">

This would require some extra JS to include/serialize in the AJAX request which I have a neat solution for too.

Instead of manually looping over the registered metaboxes and appending their data to formData, why not use a simple classname to target "classic elements" and include them in the serialization. With jQuery, this could be done in 1 line of code:
var formData = $('form.classic-js').serialize();

The beauty of this lies in it's simplicity. Adding this classname to all the metaboxes / #classic-actions would allow them to be serialized together with minimal code.

The end result is a more seamless transition to the new edit screen allowing PHP plugins like ACF and Yoast to continue working fully until we move over to blocks completely.

[pento]

After discussing this a bit more with @elliotcondon, I don't think there's a practical way to display content from these actions in a bonus meta box area.

A potential future path would be to add support for custom meta box areas to the block editor, but that's a discussion for after 5.0, I think.

[SergeyBiryukov]

In 44241:

Meta Boxes: Add the block_editor_meta_box_hidden_fields action.

Lacking an appropriate action in the classic editor, plugins that add meta boxes have historically hooked into various actions in order to add hidden input fields.

This change also adds backwards compatibility for two of the most common: edit_form_after_title, and edit_form_advanced.

Props pento, danielbachhuber.
Merges [43882] to trunk.
Fixes #45283.

[SergeyBiryukov]

In 44243:

PHPCS: Fix errors introduced in [44241].

See #45283.