Custom Fields Panel & add_meta_box function cause post to constantly think it has unsaved changes.

[albanyacademy]

Description

Enabling custom fields panel or adding a custom panel via add_meta_box causes post to always have "update" button enabled.

Step-by-step reproduction instructions

1. add new post
2. save new post
3. click update button forever.

Screenshots, screen recording, code snippet

https://www.screencast.com/t/s9r4xJO93seE

Environment info

• wordpress 6.1.1, no plugins installed

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

[albanyacademy]

noticing this is affecting third party plugins as well, like yoast.

[ndiego]

Thanks for reporting @albanyacademy. I am able to replicate it on my end as well. That said, I wonder if this is a "feature" rather than a bug. I don't know if the Editor actively detects changes to meta box fields. If it doesn't, then the "Update" button should always be enabled. Otherwise, it would remain inactive if the only changes on the page were those made to the meta boxes.

@Mamaduka do you have any insight on this?

[Mamaduka]

Thanks for the ping, @ndiego!

Yes, this is expected behavior for the "Update" button (#5399).

Why?

The editor doesn't control the state/data for fields rendered inside the meta boxes, and unlike core entities, it cannot know if data was already saved.

[ndiego]

Gotcha, that's what I thought. Thanks @Mamaduka.

I am going to close this out since this behavior is expected. Please let us know if there are any questions. Thanks!

[albanyacademy]

I really disagree that this should be expected behaviour.

Without meta box fields being open/active, if the user makes a change the button becomes disabled until new changes are made.

Having custom field panels visible changes this behaviour, but does nothing to indicate to the user why this behaviour has changed.

Going off of #5389, this doesn't sound like an intentional design decision and more a technical limitation - in that case one could argue that it is expected, but it is far from ideal.

[ndiego]

Hi @albanyacademy, thanks for the additional feedback. I completely agree with you. Ideally, this would not happen, but it's the expected behavior given the current technical limitations of metaboxes in the Editor.

[albanyacademy]

So can this ticket be reopened so action will be taken? Or is there already an open ticket addressing this?

[Mamaduka]

@albanyacademy, the issue can only be addressed by dropping backward compatibility for meta boxes. And as far as I know, there's no plan for doing that.

[albanyacademy]

That can't be the only way to address it.

edit-post/src/store can be updated to save an initial value of formdata from metaboxes, and then listen for changes inside said metaboxes.

The data is already being constructed during save:

gutenberg/packages/edit-post/src/store/actions.js

Lines 370 to 380 in 911d01a

	const baseFormData = new window.FormData(
	document.querySelector( '.metabox-base-form' )
	);
	const activeMetaBoxLocations = select.getActiveMetaBoxLocations();
	const formDataToMerge = [
	baseFormData,
	...activeMetaBoxLocations.map(
	( location ) =>
	new window.FormData( getMetaBoxContainer( location ) )
	),
	];

you could replicate this to store an initial save state on initialization, and then add simple change event listeners for backwards compat on the form element and compare saved form data by IDs - or, if performance is an issue, listen for any single change and then turn it off, regardless if user "undoes" their changes. Dirty, but better than not having any insight into the state of the available meta boxes, and this is more consistent with the default editor experience.

then expose the selector for header.js to consume:
https://github.com/WordPress/gutenberg/blob/88335dbf42f456b2c89e3fa12ade3d5170100daa/packages/edit-post/src/components/header/index.js

	const {
		hasActiveMetaboxes,
		hasUnsavedMetaBoxChanges,
		isPublishSidebarOpened,
		isSaving,
		showIconLabels,
		isDistractionFreeMode,
	} = useSelect(
		( select ) => ( {
			hasActiveMetaboxes: select( editPostStore ).hasMetaBoxes(),
			hasUnsavedMetaBoxChanges: select( editPostStore ).hasUnsavedMetaBoxChanges(),
			isPublishSidebarOpened:
				select( editPostStore ).isPublishSidebarOpened(),
			isSaving: select( editPostStore ).isSavingMetaBoxes(),
			showIconLabels:
				select( editPostStore ).isFeatureActive( 'showIconLabels' ),
			isDistractionFreeMode:
				select( editPostStore ).isFeatureActive( 'distractionFree' ),
		} ),
		[]
	);
	
	.....
	
	forceIsDirty={ hasActiveMetaboxes && hasUnsavedMetaBoxChanges }

If you're interested in this as a solution I'll be happy to get it working locally and open a PR. It's enough of an issue with our clients that it feels worth doing.