Should block-based Widgets Editor be enabled by default?

[bph]

I installed the Classic Editor plugin (v 1.6) and used a Gutenberg Master built simultaneously. The settings on the Classic Editor were set to:

• Default editor for all users: Classic editor
• Allow users to switch editors: No

When I used Appearance > Widgets - the block-based screen showed.

To reproduce
Steps to reproduce the behavior:

1. Install Classic Editor
2. Use settings from above
3. In WP-Admin go to Appearance > Widgets
4. See screen.

Expected behavior
I expected the current Widget screen to appear.

Editor version (please complete the following information):

• WordPress version: 5.5.1
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? Gutenberg
• If the Gutenberg plugin is installed, which version is it? Master as of Oct. 15

Desktop (please complete the following information):

• OS: OS X 10.15.7,
• Browser Chrome
• Version 86.0.4240.75

[bph]

Also: Not sure it needs to be fixed here:

• Should the opt-out code go into the Classic Editor?
• Should it wait until WP5.6 beta is out?

[draganescu]

This is an open discussion, but most likely if the screen will be opt-out a new option will be added for this widget editor in particular. However, the new screen might be opt-in, depending on factors such as how good the back compat will be and other issues to be found during beta.

[draganescu]

This is blocked by the decision on the default experience in WordPress 5.6 on the widgets screen.

[bph]

@draganescu Thanks for clarification and that there are still decisions to be made later in the release cycle.

[noisysocks]

@kevin940726 @talldan @tellthemachines @draganescu @TimothyBJacobs

Some decisions are required here. Should the widgets screen in 5.8 be opt-in or opt-out? Should this be controlled by the theme using add_theme_supports(), via a filter, or both? Should a seperate setting for the widgets screen be added to the Classic Editor plugin?

[TimothyBJacobs]

IMO it depends on how compatible we are. Have we sorted those issues that the most popular widgets were running into? Things like CSS/JS not being enqueued properly, or listening for non-standard events? If not, I think it should probably be opt-in.

[draganescu]

It is still not clear to me if awesome back compatibility is hard or impossible, @noisysocks. I remember some time ago you were musing around with using an iframe for the Legacy Widget's edit form. I know that block just got revamped, is that still an option?

We should aim to support all the widgets that have used standard, documented ways to extend the widgets screen or editor forms, and not support those who extend using undocumented, private APIs, including the DOM of the WP Admin screens. Something like this could shed some light and show if this aim is naive. I agree with @TimothyBJacobs that if we cannot achieve this bare minimum, then the feature cannot be opt-out. There are countless widgets with non cosmetic functionality and I can only name Woo's widgets for starters, these cannot be broken on a site update.

Should this be controlled by the theme using add_theme_supports(), via a filter, or both?

Via a filter should be enough for opting out. If somehow we land on the unfortunate necessity to make it opt in - I really hope not to get there - then theme support will have to be declared.

Should a separate setting for the widgets screen be added to the Classic Editor plugin?

This is an easy way out. Ideally we should have a setting in Settings -> User. But adding the option to opt out via a plugin sends out a clearer message about where we're headed, just like in the Post editor's case.

[spacedmonkey]

I think that this function should be opt-in via a add_theme_supports. Changing how widget work / are rendered, could / wil; break a lot of sites. We should work to make the core themes support these new block widget areas completely and use them as a good example for other theme / widget developers.

Making the feature opt-in will give developers of widgets, time to upgrade / fix issues with their widgets before a change is a rollout widely across 40% of the internet.

Once popular themes and plugins support block widget areas, we can look into at opt-in everyone by default later.

[noisysocks]

I agree with @TimothyBJacobs about backwards compatibility needing to be excellent for this to be opt-out and that that it's maybe a bit too soon to make this call. (It is not too early to think about it though!)

If we can't achieve excellent backwards compatibility then I agree with @spacedmonkey. Having the default WordPress themes opt-in to this feature would go a long way as many themes copy what the default themes do.

I remember some time ago you were musing around with using an iframe for the Legacy Widget's edit form. I know that block just got revamped, is that still an option?

Yes, it's definitely still an option, but I am thinking that we won't need to do it because the Customizer manages to support third party widget controls without embedding the widget control into an iframe.

We should aim to support all the widgets that have used standard, documented ways to extend the widgets screen or editor forms, and not support those who extend using undocumented, private APIs, including the DOM of the WP Admin screens.

I agree with this in principle but it's not so simple 🙂 There isn't really a JavaScript API for widgets aside from events like $( document ).on( 'widget-added', ... ). Interacting with the DOM is what most widgets including Core widgets such as Text and Image does. The closet we have to an "official API", in my opinion, is the events and DOM that are consistent between widgets.php and customize.php. This is what we should strive to support.

[noisysocks]

Renaming this to better reflect the pending decision. Note that we now have a Classic Widgets plugin which turns off the new screen.

[fklein-lu]

After having spent quite some time with the new Widgets Editor, I consider that it's a big step forward.

However it's also clear that enabling this by default will lead to poor results. I tested with the latest Trunk, and using the Twenty Twenty-One theme.

This is what adding a List block looks like:

The admin styles look very poor, because they originate from /wp-includes/css/dist/block-library/reset.css. The frontend looks nothing like the admin preview, because Twenty Twenty-One removes bullets from all lists.

All of these issues are solvable, however they require a lot of work. Theme authors would need to test every block in every widget area with distinct styles. And they'd need to do that for all their themes, and before the release date in July.

In my view, and many of the other commenters on this thread, it's clear that this needs to be opt-in.

[draganescu]

The ecosystem of WordPress is huge so it's hard to have a definite opinion and a bullet proof measuring system. I personally believe that currently the Legacy Widget block is ensuring stellar backward compatibility and hence strongly support having the widgets editor as opt-out (the default experience starting with WordPress 5.8).

So far in my testing all the problems that appear are usually because of a workaround implementation and can easily be fixed by following the documented extension points. The styling issues should be solved and I am convinced that later iterations will make it even better, but as it is today it's debatable if the styling problems are a good reason to hold back, considering that the classic system is an abstraction with no preview.

One of the awesome achievements of the widgets editor is the integration of the block editor with the customizer. Making this opt-in will hold back an experience that is, not holding back in saying it, revolutionary: direct interaction with and manipulation of content with instant live preview, a huge step forward from the form based boxes that carried the weight of customization for so many years.

All in all, up to this point (WordPress 5.8 Beta 1) it does not appear to me that either in the Gutenberg repo or in core Trac any blocker for opt-out has been raised (the time is not past, and I have not read every issue or ticket). In absence of a major compatibility issue, or some other issue that affects websites, a superior user experience should not be opt-in, but opt out for catering to edge cases.

[TimothyBJacobs]

I agree @draganescu, I personally thing it's fine for this to be opt-out at this point. I do think we should probably make sure that with the settings @bph had in the Classic Editor that the widgets block editor is also disabled out of the box. But that probably needs to happen in the wordpress/classic-editor repo, not here.

[noisysocks]

At this stage I'm comfortable with releasing the widgets editor in 5.8 as opt-out because:

• There are no open reports of major backwards compatibility issues, particularly with the Legacy Widget block.
• All major bugs (Priority 1 and Priority 2 in the project board) have been fixed as of WP 5.8 beta 3.
• We have 4-6 developers working on this project which gives us plenty of capacity to fix bugs during the RC period.
• There are documented ways to disable the new editors via remove_theme_support and via the Classic Widgets plugin.

I'm also optimistic that the team can continue to iterate on this feature after 5.8 is released. #32723, #32311, and #26170 all feel to me like good candidates for enhancements to make in 5.8.x or 5.9.

I'm going to close this issue out for now, though of course we can re-open and re-evaluate if new information comes to light 🙂

I agree @draganescu, I personally thing it's fine for this to be opt-out at this point. I do think we should probably make sure that with the settings @bph had in the Classic Editor that the widgets block editor is also disabled out of the box. But that probably needs to happen in the wordpress/classic-editor repo, not here.

Could you please create an issue in the Classic Editor repo?

[johnstonphilip]

@draganescu The experience of the block editor in the customizer being "revolutionary" is definitely subjective. The fact that the block-editor-sidebar (aka inspector) is completely hidden behind multiple clicks, and first-class/important block-controls live in that area, makes the block editing experience in the customizer more difficult and completely unlike the rest of WordPress, creating disparate experiences for the same utility.

Also, using a WYSIWYG editor as a data-entry-form is a very strange UX decision to me. You can see what I mean with this screenshot

I really believe this needs to be opt-in.

[talldan]

I do think we should probably make sure that with the settings @bph had in the Classic Editor that the widgets block editor is also disabled out of the box.

It might be an unusual option, but what if the user wants to have the classic post editor enabled, but also the block-based widget editor enabled?

I'm also unclear on how the 'Allow users to switch editors' option would work for widget editors. If the options in the classic editor plugin are being respected, I think that needs to work too.

[draganescu]

@johnstonphilip I agree, that is my opinion: it is revolutionary. I think one of the bits I fail to see eye to eye here is that the sidebar in the Customizer is for "data entry". I think it is for content manipulation and that the form based approach was a technological compromise of the past.

Also, yes to that mock-up. We're both in the same boat here. I referenced the previous discussions on slack and looking there you'll see I actually was the one to propose an animated mock-up containing "in-preview editing" of blocks. However the technical reality of that option is unrealistic today. I still hope the advancements we have obtained by embedding a block editor in the Customiser are a bedrock to build what we both think would be ideal.

[johnstonphilip]

@draganescu It's for data-entry because you're not experiencing what it actually looks like, and not in the same context at all. Therefore you can't use it for actual design (WYSIWYG), but just for data entry. Worse still, none of those data entry fields are labelled at all. Really take a look at my screenshot, and notice how the things on the left do not-at-all look like the things on the right, and imagine all the guess work you have to do to actually use that.

Regardless, I get the point that this is not a good use of my time to keep providing this feedback. It is what it is, and that's how it is. I don't like it. It's still happening. All good. That's open source!