Adds a new option to core/editor to disable code editing

[draganescu]

Description

Closes #14647. This adds a new option codeEditingEnabled which the block_editor_settings filter in WP Core can set to false (default is true), case in which the post editor will have two changes reflected:

• the more tools and options menu (vertical dots menu top right) will not show the option to switch between code and visual
• the blocks themselves will not have the option for HTML editing @myleshyson I thought that'd be a good idea, as no code editing means no code editing :)

How has this been tested?

1. Set the codeEditingEnabled editor setting to false with a plugin (or hack it in edit-form-blocks.php)
2. Observe the block editor while editing a post, you cannot edit the code anymore.

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[draganescu]

I think this is the first time Travis is right.

[draganescu]

updated the failing tests, should be ok for review @gziolo :)

[talldan]

Hey @draganescu - I found one edge case that may or may not need to be addressed.

If I'm one of many users on a site, and I've switched my editor into Code Editor, I believe it's saved as a preference in local storage.

If an admin then disables the Code Editor using this solution as it stands, when I return my editor will still be in Code Editor mode. I can switch back using the 'Exit Code Editor' button, but it still gives me access that to something where the intention was to disable it.

Not sure what the right solution to solve that is. We could override the result of getEditorMode where it's called. That would definitely add some extra cruft to the codebase. Or we could try to dispatch an action to switch the user back.

Alternatively, it may just be something that we live with.

The only other feedback I have is that an e2e test might be nice, but I'm not sure if there's a way to toggle the editor setting before running the assertions.

[gziolo]

If I'm one of many users on a site, and I've switched my editor into Code Editor, I believe it's saved as a preference in local storage.

If an admin then disables the Code Editor using this solution as it stands, when I return my editor will still be in Code Editor mode. I can switch back using the 'Exit Code Editor' button, but it still gives me access that to something where the intention was to disable it.

Does it mean that the value saves in local storage takes the precedence over what you set programmatically? The main use case is going to be that someone disables code editor with PHP code.

Edit: I think I now understand what @talldan said. So the issue is when I'm in Code Editor mode and the server gets updated. Next time I visit my editor, Code Editor is disabled but it gets loaded because of the mode stored in the local storage. It definitely should be covered. It seems like a bug.

There are two remaining tasks:

• there needs to be documentation included so people could discover this feature
• we should double check if there is any additional work necessary on WordPress core side, it's probably already handled with the following block_editor_settings filter

[draganescu]

Rebased and updated with code review. Remaining:

• document the option
• resolve the loading of the setting from LS

@gziolo I only tested by using the filter block_editor_settings and it works simply by adding a codeEditingEnabled key set to false. There appears nothing is required in WP Core PHP.

[draganescu]

Regarding documentation, @gziolo I couldn't find a list of editor settings, it appears that none of these is documented:

	'alignWide'              => $align_wide,
	'availableTemplates'     => $available_templates,
	'allowedBlockTypes'      => $allowed_block_types,
	'disableCustomColors'    => get_theme_support( 'disable-custom-colors' ),
	'disableCustomFontSizes' => get_theme_support( 'disable-custom-font-sizes' ),
	'disablePostFormats'     => ! current_theme_supports( 'post-formats' ),
	/** This filter is documented in wp-admin/edit-form-advanced.php */
	'titlePlaceholder'       => apply_filters( 'enter_title_here', __( 'Add title' ), $post ),
	'bodyPlaceholder'        => $body_placeholder,
	'isRTL'                  => is_rtl(),
	'autosaveInterval'       => AUTOSAVE_INTERVAL,
	'maxUploadFileSize'      => $max_upload_size,
	'allowedMimeTypes'       => get_allowed_mime_types(),
	'styles'                 => $styles,
	'imageSizes'             => $available_image_sizes,
	'richEditingEnabled'     => user_can_richedit(),
	'postLock'               => $lock_details,
	'postLockUtils'          => array(
		'nonce'       => wp_create_nonce( 'lock-post_' . $post->ID ),
		'unlockNonce' => wp_create_nonce( 'update-post_' . $post->ID ),
		'ajaxUrl'     => admin_url( 'admin-ajax.php' ),
	),

There is this https://developer.wordpress.org/reference/hooks/block_editor_settings/ documentation on the fact that the filter exists :)

[draganescu]

@talldan this is my measly solution to the local storage pref. It does the job: if you have text in the preference but someone disables via server side filter the codeEditor then you end up in visual while your preference remains text.

[gziolo]

Regarding documentation, @gziolo I couldn't find a list of editor settings, it appears that none of these is documented:

It doesn't sound right. We should include at least this new setting in the docs and start a section for block_editor_settings in Gutenberg docs as well. Other filters are documented here:
https://github.com/WordPress/gutenberg/tree/master/docs/designers-developers/developers/filters
It seems like editor-filters.md would be the best fit.

[gziolo]

I'm looking forward to seeing the remaining comments addressed as I'd like to ✅ this PR. It's nearly ready :)

[draganescu]

@swissspidy I am back on it starting today!

[gziolo]

Great work on this PR. Feel free to merge once Travis is green. There was some unrelated failure on one of the jobs so I restarted it.