Opened 6 years ago
Last modified 6 years ago
#4228 new task (blessed)
Gutenberg theme: Remove reliance upon the plugin
Reported by: | dd32 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | General | Keywords: | |
Cc: |
Description
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.
Change History (6)
This ticket was mentioned in Slack in #core-editor by dd32. View the logs.
6 years ago
#2
@
6 years ago
- Summary changed from Gutenberg: Remove reliance upon the plugin to Gutenberg theme: Remove reliance upon the plugin
#5
in reply to:
↑ 3
@
6 years ago
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).
#6
@
6 years ago
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
totemplate_redirect
, where it then does the same job thatwp-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
[8480] is related to this. @aduth / @coffee2code did that commit completely remove the requirement?