Meta-box compatibility warnings

[johnjamesjacoby]

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.

[johnjamesjacoby]

WP User Profiles

[johnjamesjacoby]

Easy Digital Downloads

[johnjamesjacoby]

bbPress

[johnjamesjacoby]

BuddyPress (Activity)

[swissspidy]

Related: #45112

[johnjamesjacoby]

BuddyPress (Groups)

[johnjamesjacoby]

BuddyPress (Emails)

[johnjamesjacoby]

WP Multi Network

[afercia]

Related:

• #45112
• #45172
• ​https://github.com/WordPress/gutenberg/issues/11058

[johnjamesjacoby]

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.

[Offereins]

"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]

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

[pento]

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.

[pento]

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.

[johnjamesjacoby]

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?

[pento]

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.

[johnjamesjacoby]

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.

[SergeyBiryukov]

Reopening for trunk.

[atimmer]

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.