Classic Editor fails to load in Visual edit

[bobbingwide]

Issue Overview

If an extension plugin responds to enqueue_block_assets and it enqueues its own script, with dependencies on Gutenberg's scripts, then this can break the Classic Editor in Visual mode.

Steps to Reproduce (for bugs)

1. Deactivate Gutenberg
2. Create a new post in Text mode with any content you like.
3. Save
4. Activate Gutenberg and a plugin that responds to enqueue_block_assets using code similar to below.
5. Edit the post using the Classic Editor.
6. Attempt to switch to Visual.
7. The Visual editor does not load.

    wp_enqueue_script(
        'oik_block-blocks-frontend-js',
        plugins_url( $blockPath, __FILE__ ),
        [ 'wp-i18n', 'wp-element', 'wp-blocks', 'wp-components', 'wp-api' ],
        filemtime( plugin_dir_path(__FILE__) . $blockPath )
    );

Expected Behavior

You should be able to toggle between the Text and Visual editor modes without failure.

Current Behavior

You can merrily edit in Text mode, but attempting to switch to Visual will lead to an empty TinyMCE window with no icons. Once this has happened it's very difficult to get back to Text without deactivating a plugin or two.

Possible Solution

When using the Classic Editor there should be no need for Gutenberg blocks.
The classic-editor parameter is passed in the request and is available from $_GET.

A new test is required to avoid invoking enqueue_block_assets.

As a workaround, for my plugin, I added the test to my own action hook function.

Screenshots / Video

Related Issues and/or PRs

This was originally raised as Scenario 3 in #4672.

Todos

• Tests
• Documentation

[bobbingwide]

There's a similar problem with the Text Widget.
We'll have to put some more work into PR 4693.

This animated gif (sorry, it's a bit fast) shows

• the Text widget displaying correctly, when gutenberg_common_scripts_and_styles was not being called.
• I then re-enabled the function and refreshed the page.
• The TinyMCE display is not working.
  
  There are lots of messages in the Console log

The easiest way to fix this appears to be to remove

add_action( 'admin_enqueue_scripts', 'gutenberg_common_scripts_and_styles' );

[aduth]

The easiest way to fix this appears to be to remove

add_action( 'admin_enqueue_scripts', 'gutenberg_common_scripts_and_styles' );

Wouldn't this break all blocks which enqueue for the actual Gutenberg editor screen?

[bobbingwide]

Wouldn't this break all blocks which enqueue for the actual Gutenberg editor screen?

No, see the table that I have created in bobbingwide/oik-block#8

These blocks are enqueued in response to enqueue_block_editor_assets, which gets called by gutenberg_editor_scripts_and_styles() which is attached to admin_enqueue_scripts if replace_editor is true.

[bobbingwide]

I've revisited this issue with an update to the Text Widget part of the problem.
First, I changed my plugin to register the scripts in response to init and only enqueue them when safe.

When responding to enqueue_block_editor_assets it checks what's happening.

if ( doing_filter( "replace_editor" ) ) {
  wp_enqueue_script( 'oik_block-blocks-js' );
}

When responding to enqueue_block_assets it checks that it's the frontend.

if ( is_admin() ) {
  return;
}
wp_enqueue_script( ...

But when the scripts are defined using register_block_type

register_block_type( 'oik-block/dummy', 
  [ 'render_callback' => 'oik_block_dummy' ,	
  'editor_script' => 'oik_block-dummy-js', 
  'script' => 'oik_block-dummy-js'
  ] );

and the script has been registered with dependencies on [ 'wp-blocks', 'wp-element' ] then
the problem with the Text Widget still occurs.

The fix for this is either to not register scripts that have these dependencies
or to change gutenberg_enqueue_registered_block_scripts_and_styles
to only enqueue them in the front-end.

if ( ! empty( $block_type->script ) && !is_admin() ) {
  wp_enqueue_script( $block_type->script );
}

Comments appreciated.

[aduth]

@bobbingwide Could you boil this down to a minimal reproducible case? I'm trying to reproduce unsuccessfully, registering a block during init which includes [ 'wp-blocks', 'wp-element' ] in its script dependencies, but am not observing the same issues.

[bobbingwide]

@aduth Just to confirm that the Classic editor loads but the Text widget doesn't. Have you tried that part of the problem?

[aduth]

Yes, I tried using the Text Widget and it loaded okay in my minimal example. Here's the code I have in its entirety:

<?php
/*
 * Plugin Name: Demo Block
 */

function demo_block_init() {
	wp_register_script(
		'demo-block',
		plugins_url( 'demo-block.js', __FILE__ ),
		[ 'wp-blocks', 'wp-element' ]
	);

	register_block_type( 'demo/demo-block', array(
		'editor_script' => 'demo-block',
	) );
}
add_action( 'init', 'demo_block_init' );

(Tried both script and editor_script)

[bobbingwide]

Your code fails for me when it's register_block_type with 'script' => 'demo-block'. Still getting the same console messages as in #4678 (comment)

[danielbachhuber]

@bobbingwide Is this still an issue?