#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
- Have a clean WordPress.org installation
- 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' ); }
- Visit /wp-admin and activate this plugin.
- 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.
- Click the three dots menu in the top right.
- Click "preferences" at the bottom. Screenshot:
- A modal appears. Click panels on the left.
- Turn on "Custom Fields". Screenshot:
- See message asking to enable and reload, click the button. Screenshot:
- Page reloads
- 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 toundefined
in JavaScript. Code link 1, Code link 2. - PHP cannot set
$editor_settings['enableCustomFields']
equal toundefined
, becauseundefined
is not a value in PHP. It can set totrue
,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.
3 years ago
#1
- Keywords has-patch added
#3
@
3 years 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
@
3 years 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
3 years ago
#5
It looks like we're going with a change only on the gutenberg side: https://github.com/WordPress/gutenberg/pull/33931
### 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:
$editor_settings['enableCustomFields']
to anull
value instead of unsetting it.getEditorSettings().enableCustomFields === null
in addition to the already existing=== undefined
condition.### Trac Ticket
Trac ticket: https://core.trac.wordpress.org/ticket/53883