Unexpected content changes toggling Classic editor from Text to Visual to Text

[bobbingwide]

Issue Overview

When using the Classic Editor editing a post detected as Gutenberg, strange things happen to the content when toggling between Text and Visual.

I've seen unwanted paragraphs being created and content disappearing.

This is a backward compatibility problem.

Steps to Reproduce (for bugs)

1. Edit a new empty post with the Classic editor, Text view.
2. From the post list open in the Classic editor
3. Paste in the following

<!-- wp:core/shortcode -->
[bw_table fields=title,featured]
<!-- /wp:core/shortcode -->

4. Toggle to Visual and back again. Looks OK.
5. Update
6. Now toggle again. Unwanted paragraph tags appear around the shortcode.

Expected Behavior

When using the Classic editor you should be able to toggle between Visual and Text without changes to the content.

This unwanted behaviour happens even when the post type being edited does not have 'show_in_rest'.

Current Behavior

Possible Solution

Screenshots / Video

Related Issues and/or PRs

Todos

• Tests
• Documentation

[bobbingwide]

Scenario 2

Blank appearing in empty divs.

When any HTML comment is added to the content that Gutenberg treats as being a block then toggling between Text and Visual adds an unwanted blank in empty divs.
e.g.

<div class="my-content"></div>
<!-- wp:jsforwp/register-demo -->
<div class="my-content"></div>
<!-- /wp:jsforwp/register-demo -->

becomes

<div class="my-content"> </div>
<!-- wp:jsforwp/register-demo -->
<div class="my-content"> </div>
<!-- /wp:jsforwp/register-demo -->

• this is a backward compatibility issue in the Classic editor.
• It affects post types which are not 'show_in_rest'.

[bobbingwide]

Scenario 3

Classic editor fails to complete loading.
Here's a block taken from Zac Gordon's course. https://github.com/zgordon/gutenberg-course

<!-- wp:jsforwp/register-demo -->
<div class="wp-block-jsforwp-register-demo">
<h2>Block Demo</h2>
<div class="my-content"></div>
</div>
<!-- /wp:jsforwp/register-demo -->

1. Deactivate Gutenberg
2. Create a new post and paste the above content in Text edit.
3. Save
4. Switching from Text to Visual then back again loses the first comment. See note 1.
5. Activate Gutenberg and the Gutenberg-course plugin that registers the block
6. Edit the post using the Classic Editor
7. Attempt to switch to Visual.
8. The Visual editor does not load.

Notes: I think that the unexpected removal of the first comment line is:

1. A core TinyMCE bug ( noted in 4.9.2 and 5.0-alpha-42125-src)
2. But it's not a problem when Gutenberg is active.

My server log shows a lot of file requests being passed to WordPress
The problem goes away if I comment out the code that enqueues the front-end JavaScript file, called in response to enqueue_block_assets.

    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 )
    );

I don't understand why gutenberg_common_scripts_and_styles() is invoking this action when it's the classic-editor. REQUEST_URI=/hm/wp-admin/post.php?post=20905&action=edit&classic-editor

[bobbingwide]

For Scenario 1 and 2 the workaround/fix seems to be to do the opposite of the logic in
gutenberg_disable_editor_settings_wpautop
by setting wpautop to true.
or to de-register the filter function added in compat.php

remove_filter( 'wp_editor_settings', 'gutenberg_disable_editor_settings_wpautop' );

This change has a different side effect. Whereas p tags are not created around the shortcodes
those which do exist in are converted to blank lines.

<!-- wp:core/paragraph -->
<p>Now I am writing a paragraph and all is fine. In a moment I&#x27;ll switch back to the Classic editor and see what&#x27;s what.</p>
<!-- /wp:core/paragraph -->

After the round trip from Text to Visual and back the content becomes.

<!-- wp:core/paragraph -->

Now I am writing a paragraph and all is fine. In a moment I'll switch back to the Classic editor and see what's what.

<!-- /wp:core/paragraph -->

[danielbachhuber]

@bobbingwide Is this issue still valid?

[danielbachhuber]

I can still reproduce the original issue as of master (to be Gutenberg 3.1):

[danielbachhuber]

@tofumatt This could use an e2e test if you want to write one for it.

[tofumatt]

From the issue history here it seems this is still relevant, so I can write a failing e2e test and mark it to be skipped, but the actual issue isn't resolved, correct?

[danielbachhuber]

From the issue history here it seems this is still relevant, so I can write a failing e2e test and mark it to be skipped, but the actual issue isn't resolved, correct?

Correct, the actual issue isn't yet resolved. If you're in the mode of writing e2e tests though, I think this would be high-value to have covered.

[danielbachhuber]

This issue has been flagged as high-value by Bluehost for Try Gutenberg rollout.

[aduth]

This was meant to be at least partially addressed with the following snippet introduced with #2708:

gutenberg/lib/compat.php

Lines 72 to 87 in 322a3fc

	/**
	* Disables wpautop behavior in classic editor when post contains blocks, to
	* prevent removep from invalidating paragraph blocks.
	*
	* @param array $settings Original editor settings.
	* @return array Filtered settings.
	*/
	function gutenberg_disable_editor_settings_wpautop( $settings ) {
	$post = get_post();
	if ( is_object( $post ) && gutenberg_post_has_blocks( $post ) ) {
	$settings['wpautop'] = false;
	}
	return $settings;
	}
	add_filter( 'wp_editor_settings', 'gutenberg_disable_editor_settings_wpautop' );

In brief testing, we are passing the setting, though apparently it's not enough to stop the forced paragraphs from being introduced.

I wonder if these tags may be introduced via TinyMCE's forced_root_block setting. It's not clear to me how we could exempt blocks from this without otherwise diminishing the behavior of the editor.

[danielbachhuber]

@aduth @azaozz Crazy idea: Disable Visual mode in the Classic Editor if blocks are detected. There would be a notice communicating the behavior and the user would have to remove all block markup in order to restore Visual mode.

[aduth]

Not that crazy. It would certainly lose some convenience, but I imagine it's better to lose the convenience than the data loss (and subsequent Gutenberg-blaming) associated with TinyMCE's destructiveness toward the blocks structure.

[danielbachhuber]

@aduth @azaozz @pento I put together a patch in https://core.trac.wordpress.org/ticket/44617 that modifies TinyMCE 'BeforeSetContent' and 'SaveContent' behavior to strip <p> paragraph tags from Shortcode Blocks. In this scenario, #2708 would be reverted.

[danielbachhuber]

@WordPress/gutenberg-core Per the Slack conversation (on Saturday, sorry for working on the weekend), what's the plan moving forward with regards to opening Gutenberg posts in the Classic Editor?

[danielbachhuber]

@pento, @aduth and I chatted about this on Zoom today. Rather than try to get TinyMCE to work with Gutenberg posts, we're going to create a warning UX instead #8213