Can't insert a Classic Block in a Sidebar on the Widgets (beta) screen

[maddisondesigns]

Describe the bug
Can't insert a Classic Block in a Sidebar on the Widgets (beta) screen.

Video: https://cl.ly/6f67cfd45bcf

To reproduce
Steps to reproduce the behavior:

1. Go to Widgets (beta) screen
2. Click on the top Block Inserter and try to insert a Classic Block

Expected behavior
I should be able to insert any available block

Desktop (please complete the following information):

• OS: macOS 10.14.5
• Browser: Firefox Quantum 67.0
• Version: WP 5.2.1 Gutenberg 5.8.0

[draganescu]

As of Gutenberg 7.9.1 this is still an issue. <ClassicEdit> throws TypeError: window.wpEditorL10n is undefined in the console when attempting to add a Classic Block. @noisysocks do you have any pointers?

[noisysocks]

It sounds like the necessary TinyMCE scripts aren't being loaded into the WP Admin page. From memory wp_enqueue_editor() is what does this. Likely we have to add wp_enqueue_editor() or similar to lib/widgets-page.php.

[noisysocks]

I can still reproduce this.

[draganescu]

Aside from the fact that we should not be having that error, what is the point of using this block in widget areas? We have the HTML block and the paragraph block for visual formatting. What would the classic editor block offer?

[maddisondesigns]

What would the classic editor block offer?

@draganescu The ability to add multiple paragraphs to the one block. So, instead of having to fill up your sidebar with multiple Paragraph Blocks because they're so limiting and only accept one paragraph per block, it's more convenient to add a Classic Block when you want to display multiple Paragraphs of text.

[annezazu]

While this mentions sidebar, I can't include the classic block in the footer section either: https://github.com/WordPress/gutenberg/issues/25595  Happy to close this separate issue if this issue is considered enough of a duplicate.

What would the classic editor block offer?

I think there will be a period of time where people will need to adjust to the new widget screen and the classic block is a place of comfort for many. I can see it being a go to to start before transitioning over.

[draganescu]

@annezazu all are "sidebars", even footers 😆
This issue becomes, in my mind, relevant if we go the route of #25625 and initially make block widgets un-editable in the customizer. Then having just one classic block for multiple paragraphs makes sense.
Otherwise, the block editor treats multiple paragraphs the same way as if they were free flowing text in a single classic block.

[annezazu]

Totally understand that :D I just am clarifying in case it matters (you never know).

[noisysocks]

There was discussion about this during and after triage and there seems to be a consensus that we shouldn't support the Classic block in the widgets editor.

Closing this as won't fix.

[noisysocks]

Oh, sorry, there's an action item here: We should remove core/freeform from the list of supported blocks. Right now you can add it but there is an error.

[maddisondesigns]

There didn't look to be too much of a discussion on it. Allowing the Classic Block to be used in the Block Editor, but then telling people that they can't use it on the Widgets screens, seems like a really poor decision, and extremely confusing for end-users.

What's going to happen to anybody who's used a Text Widget on the classic widgets screen? Is that going to be converted to a Heading Block and multiple Paragraph Blocks?

I dread editing sidebars once this new Widgets screen is implemented and there's dozens and dozens of blocks just to replace a couple of simple Widgets.

[carlomanf]

@maddisondesigns

Allowing the Classic Block to be used in the Block Editor, but then telling people that they can't use it on the Widgets screens, seems like a really poor decision, and extremely confusing for end-users.

The user confusion over asymmetric availability of blocks/features between different editing modes is something that has been brought up in a number of issues (this one, #22875, #25498, #24900 to name a few) but the team doesn't seem interested in addressing it right now. I predict that will change once the features are rolled out and the support requests ("what happened to X block?") come flooding in.

[noisysocks]

Allowing the Classic Block to be used in the Block Editor, but then telling people that they can't use it on the Widgets screens, seems like a really poor decision, and extremely confusing for end-users.

Why?

What's going to happen to anybody who's used a Text Widget on the classic widgets screen? Is that going to be converted to a Heading Block and multiple Paragraph Blocks?

Yes. The Text widget would appear as a Legacy Widget block. Converting that Legacy Widget block into blocks would turn it into multiple Heading and Paragraph blocks.

I predict that will change once the features are rolled out and the support requests ("what happened to X block?") come flooding in.

Personally I would be very OK with this because I would prefer that we add functionality in response to a demand for it instead of having to permanently maintain functionality that nobody uses.

[talldan]

My feeling is that the classic block shouldn't be added to the screen. I didn't expand on my reasons in the slack chat so will do so here.

The classic block serves two main purposes, primarily to handle non-block (legacy) post content and to a lesser degree to provide a transition to blocks.

Neither of these needs exist on the widgets screen. There are already legacy widgets to handle legacy content and to act as the transition to blocks for users.

Adding the classic block more than anything would serve as a completely new feature in relation to the widgets screen. The problem though is that this block is not being actively developed or enhanced, it'll continue working in the editors that currently support it, but including it here would be like adding something new that is instantly legacy code. It adds overhead for maintainers, and the value for users in the future is very questionable.

[carlomanf]

Allowing the Classic Block to be used in the Block Editor, but then telling people that they can't use it on the Widgets screens, seems like a really poor decision, and extremely confusing for end-users.

Why?

I don't mean to be personal but this response is absurdly out of touch with users. There are multiple direct quotations from users in the other issues I linked to in my previous comment, users saying that they don't know why some blocks are missing from some editors and present in other editors. Are you seriously asking them what's confusing about that?

@noisysocks you were also the one who proposed to set supports.reusable = false for the legacy widget to solve #22875. Do you propose the same solution for this block, given it's the same issue involving a different block? If so, what does this mean for reusable blocks that already include classic content? Do they break?

These are quite simple scenarios that anyone with significant WP (not React) experience would easily foresee before they happen. I'm actually horrified that user-impacting decisions are being made without these kinds of scenarios being taken into account, apparently because you didn't think of them.

Again, I don't like to be personal, but what I always see when checking the profiles of people who don't foresee these side effects is they don't use WP for their own website and don't author any plugins. This isn't a problem, it just means that those who do might have some good perspectives to share with them.

I'm of the opinion that asymmetric availability of blocks between different editing modes is impossible without crippling the functionality of Gutenberg. Last time I said that over at #22875 it got dismissed with a very unconvincing comparison to Greek mythology, so I'm not holding my breath to be listened to this time.

[noisysocks]

I'm sorry you feel that you aren't being listened to.

There are multiple direct quotations from users in the other issues I linked to in my previous comment, users saying that they don't know why some blocks are missing from some editors and present in other editors.

Are you referring to #22875 (comment)? The author is asking about third party blocks in the widgets editor. These are supported. There is then a reply to that comment which refers to support for reusable blocks in the widgets editor. This needs to be implemented this is which is why #22875 is an open issue.

I also see #25498 (comment) which is about the Code Editor and Copy All Content functionality. This issue also remains open.

I don't see any feedback from users about not supporting Legacy Widget in the post editor (#24900) or not supporting Classic in the widgets editor (this issue) aside from what you and @maddisondesigns have shared.

@noisysocks you were also the one who proposed to set supports.reusable = false for the legacy widget to solve #22875. Do you propose the same solution for this block, given it's the same issue involving a different block? If so, what does this mean for reusable blocks that already include classic content? Do they break?

It is already not possible to insert a Classic block into a reusable block.

Again, I don't like to be personal, but what I always see when checking the profiles of people who don't foresee these side effects is they don't use WP for their own website and don't author any plugins. This isn't a problem, it just means that those who do might have some good perspectives to share with them.

Every WordPress contributor has a different background and brings something different to the table. There's no need for gatekeeping.

[maddisondesigns]

Allowing the Classic Block to be used in the Block Editor, but then telling people that they can't use it on the Widgets screens, seems like a really poor decision, and extremely confusing for end-users.

Why?

You're seriously asking why consistency is needed!? One of the big issues with Gutenberg, from day one, has been its lack of consistency with the way everything works. It may be a lot better than what it was two years ago, but there are still dozens of inconsistencies throughout the UI.

One of the fundamental principles of good usability is having consistency in the way systems are designed and the way they work. Beside just being good common sense, it makes it significantly easier for end-users (i.e. the millions of people using WordPress). Having consistency with the way screens, or in this case editors, work, makes it easier for people to use WordPress. This is especially so for new users who are just learning WordPress.

It's ridiculous that I need to espouse the benefits of consistency to people who are building the most important part of WordPress, the content editing functionality.

http://usabilitybok.org/principles-for-usable-design
https://uxdesign.cc/design-principle-consistency-6b0cf7e7339f
https://www.interaction-design.org/literature/article/principle-of-consistency-and-standards-in-user-interface-design

[noisysocks]

Thanks @maddisondesigns, got it 🙂

A seperate point I'd like to make is that it is possible to ship 5.6 with no support for Classic in the widget editor (and Legacy Widget in the post editor) and then add it via a plugin or in 5.7. Whereas if we ship 5.6 with this functionality then it is very difficult to remove it later due to backwards compatibility.

I appreciate the passionate discussion. I'm glad that WordPress isn't a project where nobody cares. We're obviously not arriving at a consensus here so the next best thing is to leave this for the 5.6 tech lead to make a final call.

[carlomanf]

Are you referring to #22875 (comment)? The author is asking about third party blocks in the widgets editor. These are supported. There is then a reply to that comment which refers to support for reusable blocks in the widgets editor. This needs to be implemented this is which is why #22875 is an open issue.

The author also said, "I had the idea that one would be able to use all available blocks in the widget areas." In other words, it was a surprise to her that she couldn't.

I also see #25498 (comment) which is about the Code Editor and Copy All Content functionality. This issue also remains open.

The author of that issue also said, "Ideally the widget editor has the same feature parity as the normal editor, this also makes the UI less surprising."

I don't see any feedback from users about not supporting Legacy Widget in the post editor (#24900) or not supporting Classic in the widgets editor (this issue) aside from what you and @maddisondesigns have shared.

Yes there is, the original purpose of the issue #4770 and at least one duplicate issue at #11462 were talking about widgets in post content.

@noisysocks you were also the one who proposed to set supports.reusable = false for the legacy widget to solve #22875. Do you propose the same solution for this block, given it's the same issue involving a different block? If so, what does this mean for reusable blocks that already include classic content? Do they break?

It is already not possible to insert a Classic block into a reusable block.

Yes it is, at least if you use code view.

[talldan]

Yes it is, at least if you use code view.

This is a workaround, but I don't think it's intended, thanks for reporting it.

[noisysocks]

@kevin940726 @talldan @tellthemachines @draganescu @TimothyBJacobs

This needs a decision. Should we enable the Classic block in the widgets screen or leave it disabled for now?

[paaljoachim]

I have browsed through the above comments... Brainstorming coming up.

Backing up for a moment.
To be able to replace the current Widget screen with the new it needs a lot of testing from widget plugin creators in a call for testing.
When the new widget screen replaces the old. When someone has a problem they should be able to easily report the bug AND also with a switch of a button/toggle/etc be able to go back to the old Widget screen where many users feel the comfort of the environment they are used to. It is not enough with having to add code to the functions file, as a regular user will not have enough knowledge to add the code to switch back to the old screen.

The main reason for anyone to switch to something new is that the new experience offers a better experience with additional features on can not get in the old environment. It takes gradual adoption. Meaning it needs to be simple for anyone experiencing something unpleasant to switch back to the old method if they choose to do so.

Compatibility from old to new.
In an adaption phase the regular user needs to have the tools (widgets) they are used to from the old environment. Meaning any widget that does not have a direct correlation/identical counterpart widget -> block should be included in the new Widget screen.

If it is a hacky approach. If the hacky approach shows for instance the Classic block in the Widget screen and it is usable then I will assume that the general user would not care. They just care that the widgets/blocks they are used to now can be used in the new environment.

[talldan]

My opinion hasn't changed. I still think the classic block is unrelated to the widget editing experience. It exists to provide legacy compatibility for post content, which is something the widget editor isn't concerned with.

It shouldn't be included for the same reason the legacy widget block shouldn't be included in the post editing experience. There are block-based alternatives now.

At least leaving it out of the initial release provides the option to include it later if it's clearly an incorrect decision.

Including it now though means supporting it indefinitely, which may cause more maintenance issues in the long run.

[tellthemachines]

I agree with @talldan that we should leave the Classic block out at least for version 1.

[paaljoachim]

Those are good points, Dan!

[maddisondesigns]

I disagree. If a particular Block is supported in the main Block editor, then it should be supported everywhere. Telling users that you can use certain types of blocks in one part of the editor, but you can't use them in another part of the editor, makes for a really poor user experience, and is only going to confuse users even further.

[talldan]

The classic block isn't a fully fledged block as such. An example is that it doesn't have block comment delimiters for its HTML. It's shown as a block in the UI only as this is a handy way to display freeform non-block post content within a block-based editor.

Widgets don't have this problem since all former content in widget areas is already neatly parcelled into widgets. It's easier to convert this non-freeform content to a block based system using a separate block—the legacy widget block.

[carlomanf]

A comment that I left on another issue might be relevant to this discussion.

On another note, isn't there a widget that is identical to the Classic block? It used to be called the "Black Studio" widget before being merged to core a few years ago. Perhaps that widget could somehow be re-badged as the Classic block in this editor.

[maddisondesigns]

The classic block isn't a fully fledged block as such. An example is that it doesn't have block comment delimiters for its HTML.

The only people who know this are developers who work on Gutenberg. It's completely irrelevant to your "everyday" WordPress user (i.e. the other 99%+ users of WordPress). As far as they're concerned, it's no different to any other block and as such, it should be treated the same.

[noisysocks]

If a particular Block is supported in the main Block editor, then it should be supported everywhere.

I don't think this is sustainable as we add more and more blocks and more and more types of block editor. There are lots of blocks in the site editor, for example, that don't make sense in the post editor: Post Content, Post Loop, etc.

On another note, isn't there a widget that is identical to the Classic block?

The Legacy Widget block is analogous to the Classic block in that it is how existing content is edited via the block editor. A Legacy Widget block containing a Text widget is very similar to the Classic block in that it displays a TinyMCE editor.

[draganescu]

A Legacy Widget block containing a Text widget is very similar to the Classic block in that it displays a TinyMCE editor.

I believe this the the main argument against adding a classic editor block in a widget area. Given all the other arguments above, it results that simple consistency on a high level item (All blocks should be Everywhere) is too weak of an argument for this to continue.

I will close the issue until we can find new information that would make the classic editor a requirement.