Disable the Legacy Widget block in post editor

[adamziel]

The legacy-widget block makes sense and works inside the widgets editor. It doesn't make a lot of sense in the post editor, and besides it won't even work as it has some pre-requisites (specific store available, specific user capabilities):

Let's make sure it's not possible to use it there by:

• Adding it via inserter
• Copying and pasting
• Constructing a new block from raw HTML
• Any other way

[mtias]

Given we already have multiple editors, it'd make more sense to only register it as a block in the edit-widgets context.

[carlomanf]

I have wanted to include widgets inside post content for basically as long as I've been using WP (nearly a decade) and I've been finding the legacy widget quite useful for doing that.

If the legacy widget is going to be limited to widget areas only, I assume there is a plan for a widget area block similar to this one to be added to core and made available for post content?

[adamziel]

I have wanted to include widgets inside post content for basically as long as I've been using WP (nearly a decade) and I've been finding the legacy widget quite useful for doing that.

While I can see merit in being able to use the legacy-widget block inside the post editor, I think the consensus is to move away from the widgets in favor of blocks in the long run. It really depends on the overall feedback.

There are also technical challenges. Using that block in posts may work in some cases but it's not something that block was designed for. It could result in multiple instances of the same widgets being rendered on the same page (e.g. in the sidebar and in the post). That's especially bad for old-style (or function-based) widgets where only one instance should ever exists. It also requires some additional state machinery that's not present in the post editor.

FWIW there are available block alternatives for all core widgets - would that help you @carlomanf?

[adamziel]

Solved by #25371 so I'm closing this issue. Let's discuss separately other use-cases such as using that block in the post editor.

[carlomanf]

@adamziel You say it's solved, but the issue was defined wrongly from the start. If there are technical challenges with the legacy widget inside the post editor, then the solution is to overcome the technical challenges, not to deregister the whole block. By that logic you'd be calling for the entire Gutenberg project to be called off because it has bugs.

You've also said that "it doesn't make a lot of sense in the post editor" but I don't know where you've derived evidence for that statement. I commented earlier to let you know that I do see sense in using widgets in the post editor. I'm not the only one, in fact the original issue #4770 that produced the legacy widget expressed the desire to add widgets to the post:

ISSUE:
I am using the latest version of Gutenberg 2.1.0 and I can not add theme widget with Gutenberg editor, only show default 3 widgets. it's Enhancement or bug in Gutenberg.

refer following screenshot link
http://prntscr.com/i807kj

That person was talking about his theme widgets being missing from the block inserter. This was before the widget editor even existed, so he was clearly talking about the post editor. The legacy widget made them available, perhaps there were technical challenges as you mentioned, but now it's gone altogether. We might as well reopen that issue now.

I'm very uncomfortable with blocks being deregistered on the basis of one person thinking it "doesn't make a lot of sense." As I just showed, people do expect blocks to be available when they open up the block inserter. I think what "doesn't make a lot of sense" is for a block to be available in one place and not in another. It's bad for user experience and I predict it will result in a lot of confused users asking why this block isn't showing up in the inserter. You can explain to me in as much detail as you want about why the implementation doesn't work, but non-technical users don't care. They just want to use their widget.

I'm worried this could set a bad precedent for user experience because there are some other examples of blocks not working or not making sense in certain contexts, such as the query loop and query pagination blocks being used outside of the query block. If they were similarly deregistered from the wrong contexts, you would still have users trying to access them and wondering why the block is not showing up because they don't realise it's the wrong place. Maybe this should be discussed in another issue?

Your mention of the available block alternatives for core widgets is irrelevant. We know that was never the purpose of the legacy widget. If there are native blocks then you'll just use them instead and it's happy days. Obviously the purpose of the legacy widget is cases where a plugin or theme is providing widgets and doesn't provide a block alternative for whatever reason.

Until now, the legacy widget was the only way you could access plugin widgets using a block-based theme. The widget editor is useless with block-based themes, because there is no way to invoke widget areas as the equivalent of dynamic_sidebar. The plugin I linked to in my previous comment seems to provide this feature, but this surely can't be considered plugin territory as its absence could be a major deal-breaker for users thinking of switching to block-based themes.

You did say "the consensus is to move away from the widgets in favor of blocks in the long run" and I'm glad that's the case, but this isn't about the long run it's about the short run. If we want users to move towards blocks, we have to make it easier for them to take the first step or they'll just stick with the old system.

[draganescu]

Howdy @carlomanf ! We should step back here and clarify things a little 😄

I do understand your concern about de-registering items and also about "one person" calls. They're both valid concerns. On this last item, of "one person" calls I think multiple discussion points have been had in other issues that led to the present one (even starting with the original
#4770 issue)

On the worry of de-registering this creating problems and a bad experience it's useful to note that:

• the legacy widget block still is an experimental feature and it was never (afaik) a part of a WP release, therefore de-registering it or making breaking changes to it is a valid option
• ever since the original issue you mention (Allow WP Widgets to be added as blocks #4770) there was a clear problem with allowing widgets in the post editor - there's even a bunch of comments in that issue highlighting this.

The post editor edits the post content. Widgets were not meant for post content even before blocks existed. The goal of allowing the legacy widget only in the widgets editor is to replicate the functionality as it exists today - as you say short term. Users should be able to add all the existing widgets and also add blocks to their current theme's sidebars.

My opinion is that adding widgets just as if they were regular blocks to the other editors (except the widget editor) will only create weird backward dependencies right in the content of websites, which will might weirdly block the path forward for said users. We'll need to accommodate the widget feature for even more time and always detect what to load and when.

Until now, the legacy widget was the only way you could access plugin widgets using a block-based theme.

Widgets do not have any place in block based themes. As their name suggest these themes should be made up of blocks. The legacy widget block, like the classic editor block, are surrogate blocks that make sense in classic themes, to enable interoperability with older content, but are not a great choice to support in block based themes.

I'm worried this could set a bad precedent for user experience because there are some other examples of blocks not working or not making sense in certain contexts, such as the query loop and query pagination blocks being used outside of the query block.

You make a valid point that consistency is not at its best with blocks being available only in specific contexts, but we should judge on a case by case basis. In this case, widgets are and were tied to widget areas not to post content, so not finding legacy widget in the post editor is not a glaring surprise 😃

I hope I made things a bit clearer 🙇

[carlomanf]

@draganescu Thanks for your reply. To clarify, my comments on bad user experience and user confusion was not referring to the breaking change in the experimental phase. I'm talking about the future stable version after it gets merged to core. Users will see they can add a legacy widget in one place, then they will assume they can add it in any other place and wonder why it's missing. This will be especially true for users who are using WP for the first time and are not used to widgets traditionally being separate from the post editor. If it's the same block inserter in both places, they'll expect the same blocks.

I see this same user expectation is also being reported by @paaljoachim at #22875 regarding reusable blocks:

@mapk and @draganescu

Even though I made this issue some time ago. I noticed a comment at:
https://wptavern.com/gutenberg-8-9-brings-block-based-widgets-out-of-the-experimental-stage
By Penny Suarez.
"I find this new widgets screen very confusing. I had the idea that one would be able to use all available blocks in the widget areas. For example, I would be able to add a Jetpack feedback form or a custom reusable block to the sidebar or footer. But that doesn’t seem to be the case. And if it is, then it’s all very unclear how to implement. I see very few widget blocks right now. The Gutenberg team should add a BETA tag to the plugin."

Justin Tadlock's reply:
"I did not even think to check reusable blocks. I did a quick test and didn’t see them listed in the inserter. I am guessing they are currently limiting what can be inserted into the sidebars/block-areas while this is in beta or for the “1.0” of this feature.
I’m not sure why Jetpack forms do not appear. I’ll have to do some digging to see if third-party blocks are not shown at all or if it’s specific to the plugin."

I also tested and I am seeing that reusable blocks are not showing up.

I actually don't see the "multiple discussion points have been had in other issues that led to the present one" at all. I just see a lot of consensus from many contributors that this is a feature that we eventually want to include. I could also find at least one duplicate issue at #11462, so users are clearly asking for it. Then, this issue comes out of nowhere and the feature gets removed with little justification other than "the feature has bugs, therefore we must remove it altogether."

Most concerningly of all, it seems that the sudden decision to ban widgets is negatively impacting other features, as evidenced by your own hilarious change of position regarding reusable blocks at #22875:

2020-09-10T09:17:22Z

Yes +1 to @mapk there is no intention known to me at least to hide anything. The widgets editor should support all the content the post editor supports.

2020-09-17T09:40:25Z

It's not entirely clear that the whole reusable blocks concept should exist in the widgets editor.

I'm just surprised that more focus seems to be on retro-fitting traditional widget areas to support blocks instead of providing backward compatibility for widgets in post content. The latter will ease the switch to block-based themes while the former actually gives people more reason to stick with their traditional themes.

[adamziel]

@carlomanf I see your point. I encourage you to open a new issue to discuss specifically your post editor use-case for the legacy widget block - I don’t think many people will find our conversation in this issue here and the point is not to argue but to find the best path forward.