Custom Fields Toggle cannot be turned off

[mreishus]

Scope Note

This is a coordination problem between WordPress and Gutenberg and requires changes on both sides. I have patches for both that I will be submitting shortly.

Summary

When using a plugin to disable Custom Fields in the post editor, WordPress attempts to change $editor_settings to tell Gutenberg not to render the Custom Fields settings toggle in a preferences modal. However, Gutenberg is listening for a value that is impossible to send in PHP, and the settings toggle remains visible even when the feature itself is disabled.

Steps to reproduce

1. Have a clean WordPress.org installation
2. Create wp-content/plugins/disable-custom-fields.php

   <?php
   /**
    * Plugin Name: Disable Custom Fields
    * Plugin URI: http://www.mywebsite.com/disable-custom-fields
    * Description: Disable Custom Fields
    * Version: 1.0
    * Author: Your Name
    * Author URI: http://www.mywebsite.com
    */
   
   add_action( 'add_meta_boxes', 'plugin_disable_custom_fields', 1 );
   
   function plugin_disable_custom_fields() {
       remove_post_type_support( get_post_type(), 'custom-fields' );
   }
   
   
   add_action( 'do_meta_boxes', 'plugin_meta_boxes', 10, 2 );
   
   function plugin_meta_boxes( $page, $context ) {
       remove_meta_box( 'postcustom', get_post_type(), 'normal' );
   }
   

3. Visit /wp-admin and activate this plugin.
4. Visit post editor on WordPress.org site. With this plugin enabled, ​this if condition will always trigger, and the ​unset( $editor_settings['enableCustomFields' );] always runs.
5. Click the three dots menu in the top right.
6. Click "preferences" at the bottom. Screenshot:
7. A modal appears. Click panels on the left.
8. Turn on "Custom Fields". Screenshot:
9. See message asking to enable and reload, click the button. Screenshot:
10. Page reloads
11. Re-visit the custom fields setting, see that it is turned off.

Expected to see: The entire "Custom Settings" option does not appear, because $editor_settings['enableCustomFields'] is unset by this core code.

Coordination between WordPress and Gutenberg

• Gutenberg hides the option, but only if enableCustomFields is set to undefined in JavaScript. ​Code link 1, ​Code link 2.
• PHP cannot set $editor_settings['enableCustomFields'] equal to undefined, because undefined is not a value in PHP. It can set to true, false, null, or decline to set the value at all, but none of these options work.
  • true, false, null - All fail because they are not === undefined in javascript.
  • Using unset() to not send the value at all - This is what the code currently does. It fails because when gutenberg sees no value is sent, it ​uses its default settings system to set it to false, which is also not === undefined.
• Therefore, Gutenberg wants $editor_settings['enableCustomFields'] === undefined in order to hide the toggle, but that value is impossible to send.

### Scope Note

This is a coordination problem between WordPress and Gutenberg and requires changes on both sides. I have patches for both that I will be submitting shortly.

### Summary

When using a plugin to disable Custom Fields in the post editor, WordPress attempts to change $editor_settings to tell Gutenberg not to render the Custom Fields settings toggle in a preferences modal. However, Gutenberg is listening for a value that is impossible to send in PHP, and the settings toggle remains visible even when the feature itself is disabled.

### Steps to reproduce

See trac ticket.

### Proposed solution:

• (WordPress): When custom fields are disabled, explicitly set $editor_settings['enableCustomFields'] to a null value instead of unsetting it.
• (Gutenberg): Hide the custom field toggle when getEditorSettings().enableCustomFields === null in addition to the already existing === undefined condition.

### Trac Ticket

Trac ticket: https://core.trac.wordpress.org/ticket/53883

[mreishus]

On the Gutenberg side, ​we are discussing changing the default value to undefined. This would allow the unset() to work. If Gutenberg goes with the undefined default, then no changes should be made to WP.org. I will keep this issue updated.

[mreishus]

It looks like we are going with a gutenberg change that does not need a change here: ​https://github.com/WordPress/gutenberg/pull/33931

It looks like we're going with a change only on the gutenberg side: ​https://github.com/WordPress/gutenberg/pull/33931