Custom Fields option displays when ACF is enabled

[noisysocks]

Describe the bug
When the Advanced Custom Fields plugin is enabled, the Custom Fields option displays but does not do anything.

To Reproduce

1. Install and activate Advanced Custom Fields
2. Set up an ACF Field Group
3. Create a new post
4. Click Show more tools & options
5. Select Options

Expected behavior
The Field Group that you set up should be the only option underneath Advanced Panels.

Actual behaviour
Both the Field Group and Custom Fields appears underneath Advanced Panels.

Additional context
See #3228 and #11084 for background on Custom Fields in Gutenberg.

This happens because ACF hides the Custom Fields meta box by removing postcustom from the list of registered meta boxes. The Classic editor will not show the Custom Fields meta box when postcustom is not registered. Gutenberg, conversely, will show Custom Fields whenever the current post type supports custom-fields.

[elliotcondon]

Hi @noisysocks

Can you attach some screenshots of the issue so I can replicate it on my end?
Currently, ACF creates a metabox for ALL field groups, and then uses JS/CSS to hide/show them.

Could you also elaborate a little more about the following?

This happens because ACF hides the Custom Fields meta box by removing postcustom from the list of registered meta boxes.

[designsimply]

Tested and confirmed using WordPress 4.9.8 and Gutenberg master (122e569) and Advanced Custom Fields 5.7.7 and am adding screenshots for reference:

Note: I did not see the same problem when testing with WordPress 4.9.8 and Gutenberg 4.2.0-rc.1 and Advanced Custom Fields 5.7.7.

[elliotcondon]

Hi @designsimply

Thanks for the screenshots - very clear.

Yes, we provide a setting to remove the "Default custom fields metabox" like so:
https://github.com/AdvancedCustomFields/acf/blob/a0c931588e7ed60b09f566249d820ab055fb89a2/includes/forms/form-post.php#L149-L151

It will be important to note that we run this code during the "add_meta_boxes" action with a priority of 10. Perhaps this is "after" WP has localized data for Gutenberg?

[pento]

The more accurate test would be for hasCustomFieldsSupport to be set based on whether the postcustom meta box is registered or not.

gutenberg/packages/edit-post/src/components/options-modal/meta-boxes-section.js

Line 47 in dd015c9

hasCustomFieldsSupport: postType.supports[ 'custom-fields' ],

Core and gutenberg_collect_meta_box_data() both do a post_type_supports( $post_type, 'custom-fields' ) before registering it, so that ensures the current check still happens. We'll need to shuffle a few things around to ensure the check happens after add_meta_boxes, but I don't think there are any critical issues there.

[noisysocks]

The more accurate test would be for hasCustomFieldsSupport to be set based on whether the postcustom meta box is registered or not.

This won't work because because we don't register the postcustom meta box when the Custom Fields option is turned off.

gutenberg/lib/meta-box-partial-page.php

Lines 125 to 128 in dd015c9

	$enable_custom_fields = (bool) get_user_meta( get_current_user_id(), 'enable_custom_fields', true );
	if ( ! $enable_custom_fields ) {
	$core_normal_meta_boxes[] = 'postcustom';
	}

[pento]

Okay, how about we register the postcustom meta box all the time, but switch the __back_compat_meta_box flag based on whether we intend for it to be shown in the block editor or not? This flag would correspond to the inverse of whether the Custom Fields option is switched off.

If a plugin then removes the postcustom meta box, we remove the Custom Fields option entirely.

[noisysocks]

Let me clarify some stuff so that we're all on the same page.

Before #11084:

• Gutenberg would always prevent postcustom from being registered.
• The Custom Fields meta box would appear if postcustom is registered. (In other words: never.)
• The Custom Fields option would appear underneath Advanced Panels if postcustom is registered. (In other words: never.)

After #11084:

• Gutenberg will prevent postcustom from being registered iff the enable_custom_fields user meta is set. This means that we're not initialising meta boxes or their assets for a default Gutenberg installation which is the case that we want to optimise for, see Add Custom Fields and Advanced Panels to Options modal #10676 (comment).
• The Custom Fields meta box would appear if postcustom is registered. (In other words: when they're enabled.)
• The Custom Fields option would appear underneath Advanced Panels if the current post type supports custom_fields. (In other words: for posts and pages.)

ACF removes the WordPress Custom Fields meta box by calling remove_meta_box, which is fine, except that we no longer look at that setting when determining if the Custom Fields option should appear underneath Advanced Panels.

One potential fix would be for ACF to call remove_post_type_support( 'post', 'custom_fields' ); in addition to remove_meta_box here:

https://github.com/AdvancedCustomFields/acf/blob/a0c931588e7ed60b09f566249d820ab055fb89a2/includes/forms/form-post.php#L149-L151

Okay, how about we register the postcustom meta box all the time, but switch the __back_compat_meta_box flag based on whether we intend for it to be shown in the block editor or not? This flag would correspond to the inverse of whether the Custom Fields option is switched off.

If a plugin then removes the postcustom meta box, we remove the Custom Fields option entirely.

This could work, though we'd have to change how meta boxes are initialised because right now __back_compat_meta_box is not exposed to the Gutenberg frontend.

Gutenberg only knows whether a meta box is registered or not. There's currently no way for the server to express "I know about this meta box, but I didn't render it" which is what is needed in the case that Custom Fields is registered (i.e. ACF is disabled) but disabled (i.e. enable_custom_fields is off).

[noisysocks]

https://core.trac.wordpress.org/ticket/45282 + #11476 will fix this issue in 5.0.