Opened 6 years ago
Closed 6 years ago
#45217 closed task (blessed) (fixed)
Allow falling back to classic editor via meta box registration.
Reported by: | peterwilsoncc | Owned by: | desrosj |
---|---|---|---|
Milestone: | 5.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch has-screenshots fixed-5.0 |
Focuses: | Cc: |
Description (last modified by )
The block editor handbook allows plugins to trigger a post/post type to fall back to the classic editor by setting a callback argument when registering meta boxes:
<?php add_meta_box( 'classic-only-meta-box', 'Classic editor only meta box', 'my_meta_box_callback', null, 'normal', 'high', array( '__block_editor_compatible_meta_box' => false, // Fallback to classic editor. ) );
Support for this should be introduced to core as part of the merge.
The Gutenberg feature plugin used a JavaScript redirect to determine if the fallback should be applied due to numerous edge cases, the most likely to be hit being not all add_meta_box()
calls will have run before use_block_editor_for_post()
.
Attachments (14)
Change History (48)
#4
@
6 years ago
- Keywords ux-feedback needs-design added
Thanks for the patch, @peterwilsoncc! This is a good start, I think we can use this as the base for making the experience better.
use_block_editor_with_meta_boxes()
will be called before register_and_do_post_meta_boxes()
runs, so there are likely to be a bunch of meta boxes that won't be registered at this point. Rather than having inconsistent redirect behaviour depending upon when a plugin registers a meta box, I wonder if we can do the following:
In do_meta_boxes()
, we currently don't show a meta box in the block editor if it has the __block_editor_compatible_meta_box
set to false
, the meta box is just skipped. Instead, we could show a placeholder for that meta box that asks the author if they want to use the classic interface to edit this post.
When they click on the button, we can store a flag saying that meta box X, generated by Plugin Y, version Z, registered to Post Types A, B, and C isn't compatible, and the author chose to use classic instead. For future loads of those post types, if that plugin (at that version) is active, assume that they still want to use classic, and use_block_editor_for_post_type()
could return false
.
In the classic interface, we can then show a similar message in the meta box, mentioning that they're using classic for this meta box, and do they want to go back to the block editor?
@karmatosed: How does this flow sound to you?
#5
@
6 years ago
This sounds ok to me, although I would like to be sure to have the messages checked for clarity. Just because you have a metabox you may not know what that is or the editor variations.
#6
follow-up:
↓ 7
@
6 years ago
@pento OK, I'll rework that this weekend. Are you able to suggest how I determine the plugin/theme that registered the meta box. The only thing I can think of is to use debug_backtrace()
but it seems a little expensive.
@karmatosed This is the copy I will use as placeholder until someone better at micro copy changes it:
Block editor:
The {theme|plugin} {name} version {X} has registered input fields as incompatible with the block editor. To continue using these fields, you can {link}edit {post types} posts in the classic editor{/link}.
Classic editor:
You have chosen to use the classic editor for {post types} posts due to the {theme|plugin} {name} version {X} has registering input fields as incompatible with the block editor. If you don't wish to continue using these fields, you can {link}edit {post types} posts in the block editor{/link}.
Otherwise, we can always go with Cheaten' huh? ;)
#7
in reply to:
↑ 6
@
6 years ago
Replying to peterwilsoncc:
Are you able to suggest how I determine the plugin/theme that registered the meta box. The only thing I can think of is to use
debug_backtrace()
but it seems a little expensive.
Check the ReflectionMethod
/ ReflectionFunction
thing in do_meta_boxes()
: that could be turned into a function and reused where we need it. Reflections are pretty fast, I have no problem running them all the time.
#8
@
6 years ago
Thanks @peterwilsoncc, I think we could maybe make the messages smaller. What do you think? cc @melchoyce in here and for micro-copy suggestions.
This ticket was mentioned in Slack in #design by boemedia. View the logs.
6 years ago
#10
@
6 years ago
We just discussed this in Slack, and we'd be happy to give feedback on this. Would it be possible to share a screenshot of the current state? That'd make it a bit easier to see how the size of the message will fit.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
6 years ago
#13
@
6 years ago
Hi, I submitted an alternative patch.
When a meta box is found and does not support the block editor, we continue to use the block editor but we show a fake meta box saying the meta box that was supposed to be there is not supported.
This is the first step, later we may implement the version proposed by @pento where we add a button linking to classic editor and we track in which cases we should open the classic editor.
The user is able to use the options menu to hide the "placeholder" meta box.
Any feedback is welcome.
#14
@
6 years ago
I updated the patch, to use closing ?>
instead echo
. The code becomes simpler with this change.
#15
@
6 years ago
Sorry I'm a bit late to this ticket, but I'm not sure it's a great time to be changing this behavior.
For a very long time it's been the behavior in the Gutenberg plugin, and the expectation, that if you register an unsupported meta-box, the editor falls back to classic.
The behavior has been there for such a long time that plugins might already be relying on this behavior for custom post types that make no sense being loaded in the new editor. This makes me worried about making such a change this late in the process.
Back in the day we discussed the inverse — showing a message in the classic editor, in context of the metabox in question, showing why there was a fallback: https://cloudup.com/c1XGDQ0Z722
#16
@
6 years ago
The last Patch I added performs a redirect to the classic editor using inline JavaScript. The same method the plugin used. The JavaScript is computed during the do_metaboxes call so in this approach we should catch all the meta boxes independently from when they were registered.
Independently of the method chosen we can iterate and improve it, better messages, try to catch the meta boxes when possible before the output starts, so we can use for some meta boxes a fatter HTTP redirect instead of relying on a slower JavaScript redirect, etc. But the important for now would the to choose the approach we will use in core.
This ticket was mentioned in Slack in #core-editor by matias. View the logs.
6 years ago
#18
@
6 years ago
Thank you for the two patch, @jorgefilipecosta!
@joen: The behaviour in the Gutenberg plugin was written in a super hacky way, due to there not being a good way to hook into the core behaviour. That method is not appropriate for core.
Unfortunately, it's not possible to know when there's an incompatible meta box until we're in the middle of rendering the page, as meta boxes have historically been registered at random points during the page load. The more resilient UX would be something along the lines of what I proposed earlier, but we unfortunately ran out of time to implement it.
45217.3.diff is the way to go here, I'm going to modify it a bit and post a new patch shortly.
#19
@
6 years ago
45217.2.diff iterates further on replacing the meta box with a placeholder. For users who are able to install/activate plugins, it shows a link to install or activate the Classic Editor plugin.
Once the plugin is activated, it shows a link to edit the post in the classic editor, instead.
#22
@
6 years ago
In 45217.6.diff:
- Fix the message not showing when the plugin couldn't be detected.
- Fix a PHP warning in the classic editor when the meta box is using an anonymous callback.
#23
@
6 years ago
👍 45217.6.diff looks good to me.
I tested:
- That a prompt to install Classic Editor appears in the block editor
- That a prompt to activate Classic Editor appears in the block editor
- That a warning appears above the meta box in the Classic Editor
With these variations:
- Registering the meta box using a string callback
- Registering a meta box using a
function() { }
callback - Registering the meta box in
plugins/hello/hello.php
- Registering the meta box in
plugins/hello.php
- With the ACF plugin enabled
My only minor note is that no warning shows above the meta box in the Classic Editor when the meta box is registered in a plugin with no folder (e.g. plugins/hello.php
), but I don't think that's important at all.
#24
@
6 years ago
In 45217.6.diff I suspect we'll need a wp_normalize_path()
or similar call around the WP_PLUGIN_DIR
and/or $filename statements:
if ( strpos( $filename, WP_PLUGIN_DIR ) === 0 ) { $filename = str_replace( WP_PLUGIN_DIR, '', $filename );
It'll probably be more likely to be needed on a windows platform.
#25
@
6 years ago
@dd32: Good point, thanks. 45217.7.diff normalises them both.
#26
@
6 years ago
The behaviour in the Gutenberg plugin was written in a super hacky way, due to there not being a good way to hook into the core behaviour. That method is not appropriate for core.
Thank you for the clarification. Naturally I defer to you on the feasibility of these things.
#29
@
6 years ago
- Keywords fixed-5.0 removed
45217.8.diff updates an incorrect translators comment.
This ticket was mentioned in Slack in #core by afercia. View the logs.
6 years ago
#31
@
6 years ago
- Type changed from enhancement to task (blessed)
Converting to a blessed task, 45217.8.diff can be committed after RC1.
In 45217.diff:
classic-editor
query string override for forcing fallback to the classic editoruse_block_editor_with_meta_boxes()
for compatibility checkinguse_block_editor_for_post()
src/wp-admin/edit-form-blocks.php
to allow for meta boxes registered after thedo_meta_boxes
actions are fired.