Gutenberg theme: Remove reliance upon the plugin

[dd32]

​https://wordpress.org/gutenberg/ currently requires the Gutenberg plugin as it uses functions which output the “entire editing interface”.
Now that Gutenberg is in core, and it's likely a future version of Gutenberg won't include all of the "replace the editing interface" code we're using, we need to make it work standalone with core.

My understanding from briefly looking into it, is that it'll require a lot of code duplication from wp-admin templates which weren't able to be exposed directly.

The source is available here:

• https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/gutenberg
• ​http://meta.svn.wordpress.org/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/gutenberg/

Taking into account #3992 would also be great.

[dd32]

[8480] is related to this. @aduth / @coffee2code did that commit completely remove the requirement?

[dd32]

In 8481:

Gutenberg Theme: Remove use of deprecated _wpLoadGutenbergEditor and replace it with _wpLoadBlockEditor.

This once again disables the Shortcode block from being displayed.

See ​https://github.com/WordPress/gutenberg/pull/14144
See #4228.

[aduth]

Replying to dd32:

[8480] is related to this. @aduth / @coffee2code did that commit completely remove the requirement?

I'm not entirely positive which requirement you're referring to specifically. The commit was a result of a discussion from Slack:

​https://wordpress.slack.com/archives/C02QB2JS7/p1553116607718300

To your original post, "a future version of Gutenberg won't include all of the 'replace the editing interface' code we're using" is exactly ​what's happened in the plugin. There's a bit of back-and-forth in the Slack conversation, but r8480 is a bit of stop-gap solution to reinstate functions which were removed from Gutenberg. The more permanent solution would be to render the core editor (wp-admin/edit-form-blocks.php) in some way or another.

Perhaps if your question is whether the function in r8480 could avoid the need to pursue this refactor, I suppose it's a question of whether it's something desirable to maintain, weighed with the difficulty of adapting to rendering the core editor (@tjnowell ​shared some of his own anecdotes which seem to indicate that it might not be a simple process).

[TJNowell]

I got frontenberg working with the internal block editor but it required some changes

First, I use this to figure out if gutenberg is present and active:

if ( ! function_exists('gutenberg_editor_scripts_and_styles') ) {

If so, it:

• conditionally enqueues a selection of scripts such as the hearbeat script
• polyfills get_current_screen and makes it return ''
• enqueues gutenberg_editor_scripts_and_styles

If not, it:

• calls the WP 5 enqueue assets action
• adds frontenberg_load_wp5_editor to template_redirect, where it then does the same job that wp-admin/edit-form-blocks.php does

Before the editor was merged, it was enough to enqueue the GB editor, make sure the relevant HTML was added, and that gutenberg_editor_scripts_and_styles was added on the enqueue scripts hook.

gutenberg_editor_scripts_and_styles called functions that took care of instantiating the editor, but when it was merged all that nice hookable function code got smushed into wp-admin/edit-form-blocks.php, and a lot of flexibility and power was lost. I tried including that file directly but ran into lots of issues. Frontenberg ran fine without including any WP Admin files before this, and to get that file working would require a lot of hacks, and compromises, some of which I could not work around.

So, I created frontenberg_load_wp5_editor. I started by copying the contents of that file into a function and running it on the template_direct hook. I made enough changes to get it working, then made additional changes based on Frontenbergs specific use case. E.g. removing the metabox setup code ( metaboxes don't work anyway ), and the post locking ( why figure out if the post is locked when post locking makes the frontend unusable? Force it to unlocked ).

I also added a number of supporting functions that replace WP 5 functions used in that file, so that I can return static values, or do non-WP Admin things. This meant I didn't have to load in more WP Admin files

Finally, I adjusted the JS with a basic check:

		var fbeditor = window._wpLoadBlockEditor;
		if ( window._wpLoadGutenbergEditor ) {
			fbeditor = window._wpLoadGutenbergEditor;
		}

fbeditor then gets used to adjust a promise to intercept and cancel any PUT POST DELETE or PATCH requests so that they never get sent.

Full implementation here: ​https://github.com/tomjn/Frontenberg/blob/master/functions.php