Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#45207 closed defect (bug) (fixed)

Meta-box compatibility warnings

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by: pento's profile pento
Milestone: 5.0 Priority: normal
Severity: normal Version: 5.0
Component: Options, Meta APIs Keywords: fixed-5.0
Focuses: Cc:

Description

In the 5.0 branch, as part of merging Gutenberg, a warning is put out to the page when WP_DEBUG is on, meant to alert users which meta-boxes are incompatible.

I believe these warnings are good natured and well intended, but should be removed or revisited.

Every plugin that uses meta-boxes (including BuddyPress & bbPress) is going to end up with warnings in them. They make it impossible to have WP_DEBUG on and take screenshots of ongoing development work, without toggling the constant to remove these warnings.

Code-wise, ! is_block_editor() seems like an incorrect condition to check.

As a plugin developer, the only time I want to know if my meta-boxes aren't compatible with anything (the Block Editor specifically) is when I've registered them to be but they still aren't.

Otherwise, I already know they aren't, because I haven't flagged them as such. "Tell me something I don't know" kinda thing.

Going to attach a few screenshots to show off how bad this is right now.

Attachments (8)

Screen Shot 2018-10-26 at 3.44.37 PM.png (253.3 KB) - added by johnjamesjacoby 5 years ago.
WP User Profiles
Screen Shot 2018-10-26 at 3.48.57 PM.png (374.7 KB) - added by johnjamesjacoby 5 years ago.
Easy Digital Downloads
Screen Shot 2018-10-26 at 3.49.34 PM.png (256.7 KB) - added by johnjamesjacoby 5 years ago.
bbPress
Screen Shot 2018-10-26 at 4.01.33 PM.png (197.2 KB) - added by johnjamesjacoby 5 years ago.
BuddyPress (Activity)
Screen Shot 2018-10-26 at 4.03.58 PM.png (372.9 KB) - added by johnjamesjacoby 5 years ago.
BuddyPress (Groups)
Screen Shot 2018-10-26 at 4.05.19 PM.png (322.5 KB) - added by johnjamesjacoby 5 years ago.
BuddyPress (Emails)
Screen Shot 2018-10-26 at 4.09.37 PM.png (257.6 KB) - added by johnjamesjacoby 5 years ago.
WP Multi Network
Screen Shot 2018-10-28 at 9.14.53 PM.png (78.0 KB) - added by kevinwhoffman 5 years ago.
Adding Give to the list of plugins where this notice is present.

Change History (22)

@johnjamesjacoby
5 years ago

Easy Digital Downloads

@johnjamesjacoby
5 years ago

BuddyPress (Activity)

#2 @SergeyBiryukov
5 years ago

  • Component changed from General to Options, Meta APIs

#4 @johnjamesjacoby
5 years ago

In the above screenshots, for these plugins, if they never support a block-based editor interface, that would probably be totally OK.

None of the text in these areas is so complicated, or requires so much thoughtful design, to warrant a block-based editor.

The only way forward is to have the Visual Editor (TinyMCE) and Block Editor (Gutenberg) be treated as just another available UI element, like meta boxes always have been, and like textareas and inputs and buttons and links.

There is no reason to migrate everyone in the entire WordPress ecosystem away from the original meta box API. Not everything that uses TinyMCE needs Blocks. I bet most things don’t. It will be confusing to users to force it.

Also, these warnings will trigger an insane amount of support burden, from developers of sites, to developers of plugins.

It’s one thing to want Blocks someplace they aren’t. It’s another to inject HTML into the markup of plugins that will never need Blocks.

Thinking about this overnight, it is my opinion these warnings need to be removed entirely.

Last edited 5 years ago by johnjamesjacoby (previous) (diff)

#5 @pento
5 years ago

  • Milestone changed from Awaiting Review to 5.0

#6 @Offereins
5 years ago

"As a plugin developer, the only time I want to know if my meta-boxes aren't compatible with anything (the Block Editor specifically) is when I've registered them to be but they still aren't."

To me, this is the most relevant issue. For a long time to come, the Block Editor will not be the one interface to rule them all. The Metabox API has way more (plugin) applications than just the edit/post pages.

@kevinwhoffman
5 years ago

Adding Give to the list of plugins where this notice is present.

#7 @pento
5 years ago

  • Owner set to pento
  • Status changed from new to assigned

Thanks for the feedback, everyone. There are a couple of bugs here that are causing the message to appear when it shouldn't.

  • Obviously, it shouldn't be appearing on any other page in the admin, except for the classic editor.
  • It should be assuming that meta boxes are compatible with the block editor, unless they're flagged as being incompatible.

Here's the correct behaviour:

  • If __back_compat_meta_box and __block_editor_compatible_meta_box are undefined, don't show the message.
  • If __back_compat_meta_box is true, don't show the message, as the plugin author has flagged that this meta box shouldn't be rendered in the block editor, it just exists for rendering in the classic editor.
  • If __back_compat_meta_box is false, don't show the message, as the plugin author has flagged that this meta box should be rendered in the block editor, and is presumably not the cause of the classic editor interface being loaded.
  • If __block_editor_compatible_meta_box is true, don't show the message, as the plugin author has confirmed that this meta box is confirmed to work in the block editor.
  • If __back_compat_meta_box is false or undefined, and __block_editor_compatible_meta_box is false, show the message, as the plugin author has confirmed that this meta box doesn't work in the block editor, and there isn't some other UI implemented for the block editor.

This message is currently hidden behind the WP_DEBUG flag, to show plugin authors what it looks like. However, the message is ultimately intended for end users, to inform that that a particular meta box (coming from whichever plugin defined it) has caused a fall back to the classic editor interface.

Obviously, I don't really expect any plugins to define the the flags in such a way that the message shows up in their release version. 🙂 Future versions of WordPress will remove the WP_DEBUG check, and potentially draw on compatibility data from w.org to decide if a meta box is actually compatible with the block editor. This will naturally come with plenty of warnings and lead time to give plugin authors the opportunity to update their plugins, if needed.

#8 @pento
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 43839:

Meta boxes: Don't show the block editor incompatiblity message when it doesn't apply.

We should only be showing this message in the classic editor interface, for meta boxes that are marked as being incompatible with the block editor.

Fixes #45207.

#9 follow-up: @johnjamesjacoby
5 years ago

However, the message is ultimately intended for end users, to inform that that a particular meta box (coming from whichever plugin defined it) has caused a fall back to the classic editor interface

I can’t imagine a scenario where it’s a good user experience to show this warning on every incompatible meta box on any page.

If an incompatible meta box is triggering classic editor instead of blocks, isn’t the reason and result already pretty obvious?

The user can’t fix it themselves anyways; what good is it to say anything at all?

#10 in reply to: ↑ 9 @pento
5 years ago

Replying to johnjamesjacoby:

I can’t imagine a scenario where it’s a good user experience to show this warning on every incompatible meta box on any page.

That's why the current behaviour is to show the message only rarely, the intention is to continue that practice.

If an incompatible meta box is triggering classic editor instead of blocks, isn’t the reason and result already pretty obvious?

No. Outside of this message, there's nothing to indicate which meta box caused the fallback, or which plugin is generating that meta box.

The user can’t fix it themselves anyways; what good is it to say anything at all?

The user can decide whether the plugin causing the fallback is really something they need, and either contact the plugin author to see if it will be updated, or choose to switch to a plugin that does offer block editor compatibility.

#11 @johnjamesjacoby
5 years ago

The user can decide whether the plugin causing the fallback is really something they need, and either contact the plugin author to see if it will be updated, or choose to switch to a plugin that does offer block editor compatibility.

I don’t believe this information or decision belongs in 5.0, when nobody will be ready.

When core features are deprecated, they are done silently. See: Links. Why advertise out-of-date-but-not-out-of-date plugins against a new feature when the old one isn’t even being deprecated.

Unless it is. If what you’re saying-not-saying is the classic editor is being deprecated, then doesn’t this message belong as a notice on the entire page, and not in the middle of eveyone’s own registered meta boxes?

Frankly, this feels like plugin-shaming folks who aren’t onboard with Gutenberg yet, and that doesn’t feel right to me. It seems like asking for more problems. I think users would be more confused if their Give forms suddenly had a Gutenberg UI instead of the same old classic editor they are used to.

Instead, the experience should be to offer some positive incentive for users to go through the painful process of tracking down plugin authors, and for plugin authors to finally get onboard.

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


5 years ago

#13 @SergeyBiryukov
5 years ago

  • Keywords fixed-5.0 added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for trunk.

#14 @atimmer
4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 44175:

Meta boxes: Don't show the block editor incompatiblity message when it doesn't apply.

We should only be showing this message in the classic editor interface, for meta boxes that are marked as being incompatible with the block editor.

Props pento.
Merges [43839] to trunk.
Fixes #45207.

Note: See TracTickets for help on using tickets.