Block editor: "Custom Fields" option doesn't work on Simple sites

[davipontesblog]

Steps to reproduce

1. Starting at URL: https://wordpress.com/block-editor/page/DOMAIN
2. Look for caterpillar menu > Options, under Advanced Panels, and check the "Custom Fields" box

What I expected

On atomic sites, the screen will refresh, and the editor adds custom field metaboxes to the bottom of the editor. On simple sites we expect the same thing to happen.

What happened instead

On Simple sites, the Custom Fields panel exists and can be checked, but it doesn't activate anything and the setting isn't actually saved (though the editor will refresh when the box is checked)

Screenshot / Video

Screenshot Simple -- https://cld.wthms.co/08rcuk
Screenshot Atomic -- https://cld.wthms.co/SB8BXB

#manual-testing

[happychait]

Also reported in 2606733-zen

[mrfoxtalbot]

I do not think Custom Fields are meant to work on simple sites at all. I checked the classic editor and there is not such option:

Following this the logical next step would be to remove this option from the "Caterpillar" menu on all simple sites.

[davipontesblog]

Following this the logical next step would be to remove this option from the "Caterpillar" menu on all simple sites.

Agree. I would think that the action item here would probably be to remove this option in both simple and atomic sites since it's likely not relevant to WordPress.com.

[mrfoxtalbot]

I would be cautious to remove it from Atomic sites unless we have a specific reason to do this. Some old school users (and/or old plugins) may rely on them.

[rickmgithub]

We had to manually add an enclosure tag the other day after a podcast RSS feed didn't work - p2EDhh-Ze-p2

At the moment we have some users asking for duration tags to be added to the RSS feed. I was going to do a test on a simple site by adding the tag manually but also noticed that simple site don't have the custom fields option.

Link to the PodcastP2 post about this too - payqFK-2Y-p2

[gwwar]

Folks investigating should check to see if this is actually whitelisted in Simple and Atomic.

[lizswafford]

Reported in 2722903-zen

[xpurichan]

Another report of confusion with this on a simple site in 2846001-zen.

[xpurichan]

I see that Davi's original screenshots are no longer working. I wanted to add that this option for Custom Fields appear not only in the classic editor but also when using the block editor; despite that I don't believe they ever worked in the block editor...

Setting is found in the block editor by:

1. Visiting a page/post to edit
2. Using the three-dot menu in the top-right corner
3. Select Options
4. Scroll down to the bottom of the page to find and select "Custom Fields". They will never load on the page, and when you re-visit this option after enabling it then you will find that it has turned itself off.

[xpurichan]

Another report in 6442402-hc

[happychait]

23326790-hc

[donalirl]

Confusion over this in #3656405-zen

[carinapilar]

User was confused that it wasn't saving the option to use the Custom Fields: 29616591-hc - explained that it's not available on Simple sites.

[formosattic]

4130667-zd-woothemes

[sajmes]

2578715-hc

[mreishus]

I don't have a fix yet, but I have determined the cause. Here's what I've found so far:

Steps to reproduce (2021, block editor)

1. Visit post editor on simple site
2. Click the three dots menu in the top right
3. Click "preferences" at the bottom
   
4. A modal appears. Click Panels on the left
5. Turn on "Custom Fields"
   
   
6. See message asking to enable and reload, click the button
7. Page reloads
8. Re-visit the custom fields setting, see that it is turned off. (Expected to see either: turned on and feature working, or option not available at all if it's not supported)
   

Desired Solution

• Our desired solution is to hide the option because we do not support custom fields on simple sites.
  • Atomic sites should retain the option.
  • Reference: Comment 1, Comment 2
  • I do not have up to date information on if the situation has changed in the last 1.5 years. I am also not yet familiar with how this option works if it's turned on, or why it's not supported on wpcom simple.

Code Location

• This is rendered by a file called meta-boxes-section.js in gutenberg.
  • It contains a guard clause checking the values of areCustomFieldsRegistered and thirdPartyMetaBoxes.
    • areCustomFieldsRegistered comes from an "editor setting" called enableCustomFields. Note that areCustomFieldsRegistered is false if and only if enableCustomFields is undefined.

enableCustomFields	areCustomFieldsRegistered	notes
true	true
false	true	<-- Current state of WPCOM Simple
0	true
undefined	false	<-- Where we want to be

• "
  • "
    • areCustomFieldsRegistered
      • This logic was added on https://github.com/WordPress/gutenberg/pull/11476/files.
      • Current value on WPCOM simple sites: getEditorSettings().enableCustomFields == false, which means derived value areCustomFieldRegistered == true
    • thirdPartyMetaBoxes
      • Take the output from getAllMetaBoxes(), remove any objects with .id == 'postcustom'. If there are 0 objects left, this condition for hiding is fulfilled. If there is at least one object, the setting can never be hidden.
      • On my WPCOM Simple test site, I am always seeing 0 objects returned from getAllMetaBoxes(), so this is not the problem.

Where are editor settings set, and how can we change them?

• WPCOM has an edit-form-blocks.php that currently (2021-08-02) exactly matches the open source version from WP.org.
  • BLOCK ONE: It sets enableCustomFields to a get_user_meta() on the current user; enable_custom_fields.
    • This was last changed in this commit. See Issue 45257
  • BLOCK TWO: It clears enableCustomFields if some conditions apply.
    • In my testing, this block of code is getting triggered and causing $editor_settings['enableCustomFields'] to be unset on wpcom simple.
  • BLOCK THREE: It passes the settings through a function called get_block_editor_settings().
• Can I modify the value of enableCustomFields in WPCOM?
  • Putting aside proper code organization, I am able to add extra settings or change other settings by editing edit-form-blocks.php on my sandbox. For example, I can add 'enableAMadeUpOption' => true, to BLOCK ONE above, or change a value like 'titlePlaceholder' => 'My Custom Title2',. Here, I can see the new values in the console when logging out getEditorSettings() inside gutenberg js.
  • No matter what I do, I cannot pass the value of enableCustomFields == undefined through to the editor settings in gutenberg. This has me feeling there must be the equivalent of code like this: enableCustomFields = enableCustomFields ?? false somewhere between WPCOM edit-form-blocks.php and gutenberg meta-boxes-section.js getEditorSettings().

WPCOM edit-form-blocks.php $editor_settings['enableCustomFields']	gutenberg meta-boxes-section.js getEditorSettings().enableCustomFields	notes
true	true
false	false
null	false	☹️
(used unset() to remove value)	false	☹️
"1234"	"1234"
1234	1234
	undefined	this is what we need, but it seems impossible

Core Conflict

The cause of the conflict seems to be something disrupting these two parts of code from communicating properly:

• WordPress.org edit-form-blocks.php realizes that since there are no wp meta boxes, it should turn off enableCustomFields. CODE.
• Gutenberg says if enableCustomFields is undefined, to not render the setting. CODE.
• Something between these two parts of code, as of yet unidentified, changes undefined values of enableCustomFields to false values. It's likely trying to set sensible defaults but this causes gutenberg to no longer see the undefined value it is looking for.
  • I have a strong hunch this is the cause: Settings Defaults in gutenberg's packages/editor/src/store/defaults.js
    • These were modified here: Clarify the block editor settings from the post editor settings WordPress/gutenberg#14082
    • After testing, this is definitely it.

Success (Sort Of)

By removing this line in gutenberg, I'm able to remove the option from appearing:

• Note that Additional section still appears. This seems to be an issue with gutenberg that nothing is guarding the display of the section header.
• I don't believe there is a PR or a patch to WPCOM code I can submit to fix this issue. To the best of my knowledge, gutenberg makes this impossible to hide: It requires an enableCustomFields to be set to undefined for it to be hidden, but if it is set with undefined, its default mechanism overwrites it with false, which is not hidden. I will need to raise the issue with gutenberg core and ask them how they would like to resolve it.
• Making this same change on an atomic site did not cause the option to hide, which is perfect.

[mreishus]

Opened gutenberg issue: WordPress/gutenberg#33830

[mreishus]

I want to understand more about the broader meaning of this setting, why it's off on wpcom, and how I can create easy steps to reproduce and possibly a bugfix on gutenboard without involving simple at all.

First of all, here's what the custom fields setting controls if it's on and working:

My WP.org site has this working out of the box.

This is controlled by some settings deep within the global array $wp_meta_boxes. In this case, we're looking inside $wp_meta_boxes['post']['normal']['core']['postcustom'], which exists by default. If it's gone, wpcom attempts to turn off the editor setting enableCustomFields.

WPCOM turns off these settings with a plugin called wpcom-meta-boxes.php. The hiding part was added in 2012; the file hasn't been touched since then.

My next steps are

• Recreating the bug using .org only; this will involve adding a small plugin to my .org site that removes custom fields, to see that the option still appears.
• Creating and submitting gutenberg patch that fixes the bug.

[mreishus]

I believe this requires coordination between Gutenberg and WordPress.org. I have opened PRs on both that fix the problem in conjunction.

• Trac issue: https://core.trac.wordpress.org/ticket/53883
• wordpress-develop PR: When custom fields meta box is removed, set enableCustomFields to null instead of unsetting WordPress/wordpress-develop#1548
• Gutenberg issue: EDITOR_SETTINGS_DEFAULTS makes it impossible to hide the custom fields toggle WordPress/gutenberg#33830
• Gutenberg pr: Allow custom fields to be hidden when enableCustomFields is null WordPress/gutenberg#33912
  • Alternative Gutenberg pr: Change default value of enableCustomFields to undefined WordPress/gutenberg#33931

[mreishus]

We have a fix merged in Gutenberg! WordPress/gutenberg#33931
It's scheduled for 11.5, and 11.4 isn't released yet; so it may be a few weeks before 11.5 is released. Then, we'll have to wait for .com to pull in the latest Gutenberg. I'm unsure when we'll exactly see the fix land on .com.

[mreishus]

I've confirmed the custom fields toggle no longer appears on wpcom simple sites. :)