Plugin: Remove replace_editor filter, extend core editor

[aduth]

Related: #11015

This pull request seeks to eliminate Gutenberg's replace_editor feature, instead allowing the default core block editor to load, changing Gutenberg's behavior to instead extend the core block editor and replace the core script handles with the Gutenberg latest versions.

Tasks separated out:

• Deprecate / remove gutenberg_add_admin_body_class (Plugin: Deprecate gutenberg_add_admin_body_class #13572)
• Defer vendor scripts to core. (Plugin: Remove vendor script registration #13573)
• Drop inline scripts in favor of override_script improvements. (Plugin: Preserve inline scripts in Gutenberg override #13581)
• Load locale data. (Bring i18n functionality up to date #12559)
• Remove Gutenberg's heartbeat proxying. (Plugin: Remove jQuery heartbeat-to-hooks proxying #13576)
• Apply Gutenberg's built editor-styles.css to editor settings by filter. (Plugin: Extract block editor styles replacement as filter #13625)
• Extract wp-editor-font stylesheet override (Plugin: Remove wp-editor-font stylesheet override #14176)
• Remove deprecated _wpLoadGutenbergEditor, gutenberg theme supports (Plugin: Remove deprecated _wpLoadGutenbergEditor, gutenberg theme supports #14144)
• Await E2E promise interactions (Testing: Await E2E promise interactions #14219)

Needs confirmation as core aligned:

• In fixing Loading a Classic block when visual editor is disabled in user profile #5667, Gutenberg filters user_can_richedit as always true in the context of the block editor. Was this implemented in core?
  • It was not implemented, but as discussed at Ignore "Disable visual editor" setting #5670 (comment) it did not need to be. See Plugin: Remove user_can_richedit filtering #13608 for removal from Gutenberg.
• Does Gutenberg still need to extend / replace the styles property from the block editor settings?
  • It's still necessary, as this is a build distributable from Gutenberg, and may need to change in source to override that provided by core.
• Gutenberg's heartbeat-to-hooks proxying must be implemented in core
  • This was already implemented. Gutenberg's handling is redundant, and proposed for removal in Plugin: Remove jQuery heartbeat-to-hooks proxying #13576.
• Confirm whether core implemented the "Screen Options" hiding equivalent to Gutenberg's screen_options_show_screen filtering
  • As best I can tell, it did not, and should. See: https://core.trac.wordpress.org/ticket/46157

[mcsf]

• In fixing Loading a Classic block when visual editor is disabled in user profile #5667, Gutenberg filters user_can_richedit as always true in the context of the block editor. Was this implemented in core?

Commented in #5670 (comment)

[aduth]

Removing the "In Progress" label. Aside from #14144, I'm considering this as ready for review. I had some trouble with the end-to-end tests, specifically around the animations disabling. I think 44351ed should make this more durable.

The review should essentially be verifying that anything we were previously doing is respected still. Most of the additional filtering was extracted to separate pull requests. Most of the removed code should now be represented otherwise as part of the default edit-form-blocks.php file which we now allow to load.

[aduth]

Build is green now 🎉

For what it's worth, I was having some issues with intermittent failures for the new tags end-to-end tests introduced in #13129 (cc @jorgefilipecosta). It should have been improved with #14219, so I might think it could have just been some caching problem.

[aduth]

@jorgefilipecosta Can you please review this in mind of rebased refactor of widgets interoperability, per changes of #13511.

[jorgefilipecosta]

I did a set of tests with legacy widgets (including JavaScript ones), and I did not notice any difference of behavior in this version when compared with the previous one. Thank you for applying these changes that isolate the legacy widget mechanism 👍

I also did some tests with metaboxes and everything worked as before.

I left a comment regarding a dependency removal that I did not understand but other than that the changes look good to me.

[jorgefilipecosta]

I'm not understanding the reason for this change. I think 'wp-block-styles' should still depend on 'wp-block-library-theme' if the theme supports them.
gutenberg_override_style calls wp_register_style with the new dependencies so even if this dependency was set in core as we are registering it again we still need to pass it.

[youknowriad]

I have vague memories that it's done in a different way in Core and this might align both approaches. The thing is, it's not possible to call current_theme_supports in the script loader in Core.

[aduth]

Yes, there's a bit more of an explanation in in the extended comment description for 2282ee4 . It still exists, but it's manually enqueued in core's implementation of the block scripts and styles function:

https://github.com/WordPress/wordpress-develop/blob/e421f26/src/wp-includes/script-loader.php#L2626-L2630

You can confirm this adding the following snippet somewhere in a theme which adds support for wp-block-styles (e.g. Twentynineteen):

add_action( 'enqueue_block_assets', function() {
	var_export( current_theme_supports( 'wp-block-styles' ) );
	var_export( wp_style_is( 'wp-block-library-theme', 'enqueued' ) );
	exit;
} );

Should display "truetrue" on the editor screen.

[jorgefilipecosta]

Thank you for the clarification @youknowriad, and @aduth.

[aduth]

I did another force-push since it seemed Travis became stuck again.

[jorgefilipecosta]

In think we should merge this soon so we have more time to test. In my tests I did not found any regression and the changes make sense to me (althougth I dont' have deep knowlodge in some of the areas).

Thank you for this changes and improvements 👍

[aduth]

Thanks for the reviews @jorgefilipecosta 👍