Command Palette lets unauthorized users switch to Code Editor

[MadtownLems]

Description

When access to the Code Editor is disabled (via $settings['codeEditingEnabled'] = false; ), it can still be accessed using the Command Palette.

Step-by-step reproduction instructions

1. Filter the Block Editor settings to disable codeEditingEnabled in the block_editor_settings_all filter

add_filter( 'block_editor_settings_all', 'disable_code_editor' ), 10, 2 );

function disable_code_editor( $settings, $context ) {
$settings['codeEditingEnabled'] = false;
return $settings;
}

3. See that Code Editing is disabled via traditional means. It's blurred out in the Menu, and ctrl-shit-alt-M does nothing.
4. Open the Command Palette and select "Toggle code editor"
5. See that you are now in the Code Editor

Screenshots, screen recording, code snippet

Environment info

WP 6.4.2, no Gutenberg plugin

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[t-hamano]

Thanks for the report. I was also able to reproduce this problem.

Also, while looking for a solution, I discovered an issue with inconsistent command actions, and issues with the Site Editor.

In the Post Editor, there is only one action: "Toggle code editor".

In the Site Editor, on the other hand, the commands change depending on the editor context.

Furthermore, in the Site Editor, the hook that disables the editor type does not seem to be applied.

function disable_code_editor( $settings, $context ) {
	$settings['codeEditingEnabled'] = false;
	return $settings;
}
add_filter( 'block_editor_settings_all', 'disable_code_editor' , 10, 2 );

Therefore, in order to comprehensively resolve this issue, I think we will probably need to follow the steps below.

• Improve command consistency in the Post Editor and the Site Editor:
  • Minor command tweaks #58148
• Ensure that codeEditingEnabled and richEditingEnabled block editor settings are correctly applied to the Site Editor as well.
• When codeEditingEnabled or richEditingEnabled is false, disable command actions for it.
  • Command Palette: Prevent mode switching if only one editor mode is available #59299

[t-hamano]

Update:

In the Post Editor, there is only one action: "Toggle code editor".
In the Site Editor, on the other hand, the commands change depending on the editor context.

This issue was resolved by #58148. It seems that it has been unified to Open code editor/Exit code editor.

[t-hamano]

Update: In #59299, switching modes via the command palette is now disabled when only one editor mode is available.

[senadir]

Hey! Is this issue is valid?

Ensure that codeEditingEnabled and richEditingEnabled block editor settings are correctly applied to the Site Editor as well.

Seems unrelated to this package maybe and should be a separate issue.

[ndiego]

Ensure that codeEditingEnabled and richEditingEnabled block editor settings are correctly applied to the Site Editor as well.

I just tested and codeEditingEnabled is applied correctly in the Site Editor and disabling the Code Editor does also remove the option from the Command Palette. Since the original issue is now solved, I am going to close this issue.

In my testing, I did notice that setting richEditingEnabled to false in the Site Editor does not work. It does in the Post Editor. I think this should be a separate issue, and I am not even sure you should be able to disable richEditingEnabled in the Site Editor. It's unclear to me what value this would provide 🤔

[t-hamano]

@ndiego Thanks for checking out this issue!

In my testing, I did notice that setting richEditingEnabled to false in the Site Editor does not work.

This is because richEditingEnabled is forced to be true in the site editor:

gutenberg/packages/edit-site/src/components/block-editor/use-site-editor-settings.js

Lines 155 to 159 in c2a8564

	const defaultEditorSettings = useMemo( () => {
	return {
	...settings,
	richEditingEnabled: true,

I would like to consider separately whether it is possible to disable this setting in the site editor as well, and whether doing so would be worthwhile.