Hiding all metaboxes prevents POST request to post.php to save meta fields

[enricobattocchi]

Description

Since WordPress 6.7, when all the metaboxes are hidden in the preferences, the POST request to post.php to save meta fields is not fired anymore as it used to (e.g. in 6.6.2).
This creates problems with plugins, e.g. Yoast SEO, that use a sidebar to allow users to change some post metadata.
In general, this is a different behaviour from what used to happen so any mechanism relying on that request being fired could be affected.

Step-by-step reproduction instructions

1. Have WordPress 6.7.* on your site
2. Install and activate only one plugin adding metaboxes, e.g. Yoast SEO
3. In the block editor, Preferences > General > Advanced, disable "Yoast SEO" and close
4. important: reload the page or edit another post - the metabox needs to be hidden from the beginning
5. open the Yoast SEO sidebar and change a setting, e.g. the focus keyphrase
6. save the post
7. no POST request is fired to post.php, so the changed value is not saved

Up until 6.6.2, a POST request was fired to post.php even with hidden metaboxes, so the new value was saved.

Important to notice: the value change in the hidden field works as expected, only the POST request is not fired anymore.

Notable finding:
if the user visits Preferences > General > Advanced, enables the metabox and then disables it again, then doesn't reload the page, the changed value will be saved instead. The problem happens only if all metaboxes are hidden since the editor page has been loaded and the relevant settings have not been touched.

Screenshots, screen recording, code snippet

https://www.loom.com/share/bdf879f26d67454caca89aa7b6c3de0b (created by a Yoast support engineer for this issue)

Environment info

• WordPress 6.7, 6.7.1
• Firefox 132 on Devuan Linux "Daedalus"
• Local by Flywheel instance with PHP 8.2.10

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[afercia]

I think the culprit is here:

gutenberg/packages/edit-post/src/components/layout/index.js

Lines 229 to 245 in b58cce6

	if ( ! hasAnyVisible ) {
	return;
	}
	const contents = (
	<div
	className={ clsx(
	// The class name 'edit-post-layout__metaboxes' is retained because some plugins use it.
	'edit-post-layout__metaboxes',
	! isLegacy && 'edit-post-meta-boxes-main__liner'
	) }
	hidden={ ! isLegacy && isShort && ! isOpen }
	>
	<MetaBoxes location="normal" />
	<MetaBoxes location="advanced" />
	</div>
	);

Previously, the 'normal' and 'advanced' metaboxes areas were still rendered and hidden with CSS.
After #64351 these etaboxes areas aren;t rendered at all. As such, there's no POST request.

[Mamaduka]

cc @stokesman

[afercia]

Reading the dev note about the split view for metaboxes, there's no mention that the rendering of the HTML has changed. As in:

When panels visibility is disabled in the Preferences:

• Previously: the metaboxes HTML was rendered and hidden with CSS.
• After: the metaboxes HTML is not rendered.

This impacts, for example, any plugin that uses hidden input fields in their metaboxes to save meta and thus trigger the POST request.

It sounds like a breaking change that was overlooked and not documented.

[afercia]

Of course, avoiding to render the HTML and run extra code is a performance benefit. However, I'm not sure this behavior can be changed without deprecating saving meta via hidden input fields in the metaboxes area and allowing a grace period for plugins to adapt.

[t-hamano]

I was not able to reproduce this issue. Is there a step I'm missing?

• WordPress 6.7.1
• Only the Yoast SEO plugin enabled
• All meta boxes disabled

eb7297de708aa91d873579ffe93133ef.mp4

[afercia]

@t-hamano thanks for testing. I'm not sure why you can't reproduce on your environment.
I just tested again on a clean WP 6.71 install and I can reproduce it. Animated GIF:

[t-hamano]

Ah, after a few tests, I was able to reproduce this issue stably. It may have been due to my environment.