WordPress.org

Make WordPress Core

Opened 8 weeks ago

Closed 5 weeks ago

Last modified 4 weeks ago

#53883 closed defect (bug) (reported-upstream)

Custom Fields Toggle cannot be turned off

Reported by: mreishus Owned by:
Milestone: 5.9 Priority: normal
Severity: normal Version: 5.8
Component: Editor Keywords: has-patch
Focuses: Cc:

Description

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: https://user-images.githubusercontent.com/937354/128374126-c22ad772-d02f-4df4-9c4b-bb9be3748a71.png
  7. A modal appears. Click panels on the left.
  8. Turn on "Custom Fields". Screenshot: https://user-images.githubusercontent.com/937354/128374210-5d7311eb-6073-4ffa-8fd5-6754ac3c5aa3.png
  9. See message asking to enable and reload, click the button. Screenshot: https://user-images.githubusercontent.com/937354/128374223-df55a53c-b4ae-4261-b664-b256ee202d28.png
  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.

Change History (7)

This ticket was mentioned in PR #1548 on WordPress/wordpress-develop by mreishus.


8 weeks ago

  • Keywords has-patch added

### 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

#2 @SergeyBiryukov
8 weeks ago

  • Milestone changed from Awaiting Review to 5.9

#3 @mreishus
7 weeks ago

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.

#4 @mreishus
5 weeks ago

  • Resolution set to wontfix
  • Status changed from new to closed

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

#5 @prbot
5 weeks ago

mreishus commented on PR #1548:

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

#6 @sabernhardt
5 weeks ago

  • Resolution changed from wontfix to reported-upstream

This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.


4 weeks ago

Note: See TracTickets for help on using tickets.