WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 6 months 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 peterwilsoncc)

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)

45217.diff (3.0 KB) - added by peterwilsoncc 8 months ago.
45217-2.diff (2.8 KB) - added by jorgefilipecosta 7 months ago.
45217.3.diff (2.7 KB) - added by jorgefilipecosta 7 months ago.
45217.4.diff (1.8 KB) - added by jorgefilipecosta 7 months ago.
45217.2.diff (7.8 KB) - added by pento 7 months ago.
Classic Plugin not installed.png (133.9 KB) - added by pento 7 months ago.
Classic Plugin not activated.png (135.9 KB) - added by pento 7 months ago.
Classic Plugin activated.png (134.0 KB) - added by pento 7 months ago.
Classic Editor view.png (120.1 KB) - added by pento 7 months ago.
Classic Plugin not installed or activated for Author user.png (111.5 KB) - added by pento 7 months ago.
45217.5.diff (8.0 KB) - added by pento 7 months ago.
45217.6.diff (8.0 KB) - added by pento 7 months ago.
45217.7.diff (8.1 KB) - added by pento 7 months ago.
45217.8.diff (657 bytes) - added by ocean90 7 months ago.

Download all attachments as: .zip

Change History (48)

#1 @peterwilsoncc
8 months ago

  • Description modified (diff)

@peterwilsoncc
8 months ago

#2 @peterwilsoncc
8 months ago

In 45217.diff:

  • Introduces the classic-editor query string override for forcing fallback to the classic editor
  • Adds a function use_block_editor_with_meta_boxes() for compatibility checking
  • Calls the new function as a part of use_block_editor_for_post()
  • Adds a second late check and forces a redirect in src/wp-admin/edit-form-blocks.php to allow for meta boxes registered after the do_meta_boxes actions are fired.

#3 @peterwilsoncc
8 months ago

  • Keywords has-patch added; needs-patch removed

#4 @pento
8 months 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 @karmatosed
8 months 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: @peterwilsoncc
8 months 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 @pento
8 months 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 @karmatosed
8 months 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.


8 months ago

#10 @JoshuaWold
8 months 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.

#11 @pento
7 months ago

#45311 was marked as a duplicate.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 months ago

#13 @jorgefilipecosta
7 months 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.

Last edited 7 months ago by jorgefilipecosta (previous) (diff)

#14 @jorgefilipecosta
7 months ago

I updated the patch, to use closing ?> instead echo. The code becomes simpler with this change.

#15 @Joen
7 months 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 @jorgefilipecosta
7 months 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.

Last edited 7 months ago by jorgefilipecosta (previous) (diff)

This ticket was mentioned in Slack in #core-editor by matias. View the logs.


7 months ago

#18 @pento
7 months 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.

@pento
7 months ago

#19 @pento
7 months 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.

#20 @pento
7 months ago

  • Keywords has-screenshots added; ux-feedback needs-design removed

@pento
7 months ago

#21 @pento
7 months ago

45217.5.diff ports GB10999 to core, as that hadn't been merged across.

@pento
7 months ago

#22 @pento
7 months 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 @noisysocks
7 months 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 @dd32
7 months 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.

@pento
7 months ago

#25 @pento
7 months ago

@dd32: Good point, thanks. 45217.7.diff normalises them both.

#26 @Joen
7 months 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.

#27 @pento
7 months ago

In 43941:

Block Editor: Add a placeholder for meta boxes that don't work in the block editor.

If a meta box is registered with the __block_editor_compatible_meta_box set to false, it's indicating that it doesn't work in the block editor. If that's the case, we can add a place holder to inform the user that they'll need to use the classic interface to work with this meta box.

Props pento, jorgefilipecosta, peterwilsoncc, karmatosed, noisysocks, dd32.
See #45217.

#28 @pento
7 months ago

  • Keywords fixed-5.0 added

@ocean90
7 months ago

#29 @ocean90
7 months 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.


7 months ago

#31 @pento
7 months ago

  • Type changed from enhancement to task (blessed)

Converting to a blessed task, 45217.8.diff can be committed after RC1.

#32 @pento
7 months ago

In 43945:

Block Editor: Clarify a translator comment in meta box handling.

Props ocean90.
See #45217.

#33 @pento
7 months ago

  • Keywords fixed-5.0 added

#34 @desrosj
6 months ago

  • Owner set to desrosj
  • Resolution set to fixed
  • Status changed from new to closed

In 44280:

Block Editor: Add a placeholder for meta boxes that don't work in the block editor.

If a meta box is registered with the __block_editor_compatible_meta_box set to false, it's indicating that it doesn't work in the block editor. If that's the case, we can add a place holder to inform the user that they'll need to use the classic interface to work with this meta box.

Props pento, jorgefilipecosta, peterwilsoncc, karmatosed, noisysocks, dd32, ocean90.

Merges [43941] and [43945] to trunk.

Fixes #45217.

Note: See TracTickets for help on using tickets.