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

Created on 30 May 2019  路  20Comments  路  Source: WordPress/gutenberg

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

screenshot_68

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
Needs Decision [Block] Classic [Feature] Widgets Screen [Type] Bug

All 20 comments

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?

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.

I can still reproduce this.

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?

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.

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.

@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.

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

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.~

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.

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.

@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.

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.

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.

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.

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 https://github.com/WordPress/gutenberg/issues/22875#issuecomment-689327703? 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 https://github.com/WordPress/gutenberg/issues/22875 is an open issue.

I also see https://github.com/WordPress/gutenberg/issues/25498#issuecomment-701949240 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 (https://github.com/WordPress/gutenberg/issues/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.

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

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.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

BE-Webdesign picture BE-Webdesign  路  3Comments

maddisondesigns picture maddisondesigns  路  3Comments

mhenrylucero picture mhenrylucero  路  3Comments

hedgefield picture hedgefield  路  3Comments

aaronjorbin picture aaronjorbin  路  3Comments