Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Widgets experimental: Not able to add reusable blocks #22875

Closed
paaljoachim opened this issue Jun 4, 2020 · 20 comments
Closed

Widgets experimental: Not able to add reusable blocks #22875

paaljoachim opened this issue Jun 4, 2020 · 20 comments
Assignees
Labels
[Feature] Widgets Screen The block-based screen that replaced widgets.php. Needs Dev Ready for, and needs developer efforts [Type] Bug An existing feature does not function as intended

Comments

@paaljoachim
Copy link
Contributor

paaljoachim commented Jun 4, 2020

Gridd theme https://wordpress.org/themes/gridd/ (same result with Twenty Twenty)
Gutenberg plugin 8.2.1
WP 5.4
Chrome

Is your feature request related to a problem? Please describe.
I am creating a tutorial on how to add a Back to Top button. I would like to add it to a footer widget so that it is available on every page of the site. I made it into a reusable block.
Turned on the Widget experiments. Went to the Widget experiments screen. Tried to find the reusable buttons block, but it is not there.

Screen Shot 2020-06-04 at 02 27 39

Describe the solution you'd like
Add reusable blocks to the experimental widgets inserter panel.

Describe alternatives you've considered
Well if I am going to add it here. Then I might have to create a new button....

@paaljoachim paaljoachim added [Feature] Widgets Screen The block-based screen that replaced widgets.php. Needs Dev Ready for, and needs developer efforts labels Jun 4, 2020
@paaljoachim paaljoachim changed the title Widgets experimental: Not able to add a reusable blocks Widgets experimental: Not able to add reusable blocks Jun 4, 2020
@noisysocks noisysocks added the [Type] Bug An existing feature does not function as intended label Aug 14, 2020
@paaljoachim
Copy link
Contributor Author

paaljoachim commented Sep 9, 2020

@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.
Screen Shot 2020-09-09 at 08 04 49

@mapk
Copy link
Contributor

mapk commented Sep 9, 2020

Good catch. Yes, we'll need to ensure that the Widget Editor works just like the Post Editor. Everything that is included (with the exception of Patterns) should also be included in the Widget Editor.

@draganescu
Copy link
Contributor

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.

@justintadlock
Copy link
Contributor

justintadlock commented Sep 11, 2020

Everything that is included (with the exception of Patterns) should also be included in the Widget Editor.

@mapk - Not to run this discussion off-rail, but why are patterns not going to be included?

It seems to me that theme authors will want to include specific patterns that work for sidebars. I'd even think that theme authors should have the ability to load patterns for specific types of content (e.g., post content, sidebars).

For example, I was creating a "widget wrapper" pattern in the hopes that I would be able to create a blocked box/group design to simulate traditional widgets.

@mapk
Copy link
Contributor

mapk commented Sep 11, 2020

but why are patterns not going to be included?

@justintadlock, I wasn't too sure about it myself. It didn't seem a lot of the Core patterns would be ideal in the smaller area, but if there's a desire, let's include them! You bring up great points!

@draganescu
Copy link
Contributor

It's not entirely clear that the whole reusable blocks concept should exist in the widgets editor. The main reason being that some widgets are not even supposed to be "reused". Also we making a reusable block in the widgets editor will make it available in other editors, but widgets only make sense in widget areas. It feels like an over-complication.

@paaljoachim
Copy link
Contributor Author

A widget area is just something WordPress calls a reusable section of a web site.
In it self it is really just another content area.

Main content (content that can be made in Gutenberg) is used one time only.
A widget area is usually seen throughout the site. A header, Footer, Sidebar(s).

Content available in one area should be made available in the other.

That means through the inserter we should see: Blocks, reusable blocks and patterns. Just like a regular Gutenberg area. As one can then reuse blocks and patterns one has saved also in the widget area. It would be better to just offer the Inserter panel as it is seen in Gutenberg today, and if one has to make changes later then do so at the time.

@draganescu
Copy link
Contributor

Howdy @paaljoachim, indeed this kind of consistency is something to be desired and I'd also want to highlight that reusable blocks are a sword that cuts both ways: including them in widget areas will "open the door" for widgets into other content areas.

I think that widgets should not be enhanced with special treatment that they'll need to be doing well in the new content areas and the new editors powered by blocks. So much so, that I support not having a Legacy Widget block in any other editor but the Widget editor. But, add support for reusable blocks in the Widget editor and "bam!", now we need Legacy widget everywhere 😄

Another way to look at it: can you do this currently, in the present widgets editor in WP? Is there a notion of reusable anything? There isn't to my knowledge. One can instance a widgets multiple times, but not reuse it with the same settings. So, I suggest that we augment the widget areas with blocks but not attempt to overhaul that feature altogether.

A widget area is just something WordPress calls a reusable section of a web site.
In it self it is really just another content area.

The reason I am wary about building features on top of widgets is because widgets areas are not just another content area. They're thought specifically around widgets. Even the way they're stored is different and specific to widgets. Plus any support we build extra means we'll be carrying with us into the future the problem of a million ways to do one thing.

That means through the inserter we should see: Blocks, reusable blocks and patterns.

I am not 100% up to date on patterns but those seem like a safe addition though which does not alter in any way how widgets + blocks currently work so I'd like to see them added to the Widgets editor.

@carlomanf
Copy link

carlomanf commented Sep 18, 2020

@draganescu

I think that widgets should not be enhanced with special treatment that they'll need to be doing well in the new content areas and the new editors powered by blocks. So much so, that I support not having a Legacy Widget block in any other editor but the Widget editor. But, add support for reusable blocks in the Widget editor and "bam!", now we need Legacy widget everywhere 😄

What about template part? What about the query block containing the post content block? The reusable block isn't the only way legacy widgets could leak into post content. Should those other blocks be barred from the widget editor too, simply to keep the legacy widget out of post content?

I actually foreshadowed this at #25179. If a block is registered, it needs to be registered everywhere, or the side effects become too great.

@draganescu
Copy link
Contributor

:D well @carlomanf as you can see from my shift in opinion right in this thread, I was initially in the same boat of "everything should be the same". But the truth is the more you consider what this means, the less it makes sense.

What would a template part block do in the widget areas? Nothing because a widget area already is a template part of the classic theme system. Query block is another in progress unclear kind of block. I see more use for variations of it or blocks like LatestPosts to make sense used in sidebars or footers.

If a block is registered, it needs to be registered everywhere, or the side effects become too great.

This is too harsh and unsubstantiated. We can discuss and act on each situation that appears, it's risky to assume we know everything and end up on a bed of Procrustes situation forcing things to fit a universal solution.

@carlomanf
Copy link

carlomanf commented Sep 18, 2020

@draganescu The template part in the widget area would just do the same as it would anywhere else. The only problematic case I can think of is if the template part somehow gets embedded inside itself, causing an infinite loop.

I'm in full agreement with you that we should assess each situation but you can still disable blocks while keeping them registered. If you look at #22080 it looks like some people were suggesting to deregister the post content block but they decided to solve it by rendering the block differently instead.

In cases where blocks won't work if rendered in the normal way, you could have them render differently with a helpful message that explains why it's disabled and how to use this block correctly. In other words, it would be still registered but disabled in a way. Deregistering them would just result in a lot of ugly "This block can't be previewed" messages all throughout people's editors.

@noisysocks
Copy link
Member

I think reusable blocks should be allowed in widget areas.

The Gutenberg team has more than once (I heard this a lot at WCEU a long long time ago) that reusable blocks are a lightweight way for non-developers to create custom blocks. For example: create a HTML block, add some HTML, turn it into a reusable block.

Viewing reusable blocks this way, I don't think it makes sense to restrict where they can be inserted, just as it doesn't make sense to restrict where a third party block can be inserted.

To solve the issue of not wanting to end up with a Legacy Widget block inside a reusable block, we can set supports.reusable = false on Legacy Widget.

@carlomanf
Copy link

@noisysocks

To solve the issue of not wanting to end up with a Legacy Widget block inside a reusable block, we can set supports.reusable = false on Legacy Widget.

There's not been any decision that legacy widgets should be unavailable outside of the widget editor. All discussion at #4770 and related issues between 2018 and 2019 was based on the idea that the block would be used in the post editor. If that plan is to change, it needs to be discussed and decided on, which I can't see any evidence that it has. It's concerning that decisions in this thread seem to be being made based on rumours and hearsay.

@noisysocks
Copy link
Member

noisysocks commented Oct 1, 2020

If that plan is to change, it needs to be discussed and decided on, which I can't see any evidence that it has.

Hey @carlomanf! There was discussion and a decision about this in #24900. From reading that thread, I gather that you disagree with the outcome. That's fine—disagreement is very healthy in an open source project. 🙂 Could you please create a new issue and ping the Gutenberg Core team, or, even better, raise this as a discussion topic for the next next Core Editor chat? A wider audience will be very helpful here.

Let's get back on topic. Regardless of whether we allow Legacy Widget in the post editor or not, I think that reusable blocks should be allowed in widget areas.

@carlomanf
Copy link

@noisysocks

There was discussion and a decision about this in #24900.

Not in that order, unfortunately.

Regardless of whether we allow Legacy Widget in the post editor or not, I think that reusable blocks should be allowed in widget areas.

I agree and I don't think the decision on that issue should be impacting this one.

@adamziel
Copy link
Contributor

adamziel commented Oct 5, 2020

I think that reusable blocks should be allowed in widget areas.

+1 to that, supports.reusable = false would solve the problem of ending up with multiple instances of the same legacy widget.

@adamziel
Copy link
Contributor

adamziel commented Oct 6, 2020

We need #25859 to get merged (and possibly the follow-up PR as well) before this issue can be solved.

@talldan
Copy link
Contributor

talldan commented Oct 19, 2020

Fixed by #26097

@tnchuntic
Copy link

I think this one is not yet fixed. Currently, I am encountering this issue with "Not able to access reusable blocks" in Widget Block area.

@draganescu
Copy link
Contributor

@tnchuntic in the mean time the reusable block functionality was moved to require that the block editor handle entities, which is not the case for the widgets editor afaik. So this issue is too old and back then it was fixed, but later a separate problem appeared which prevents reusable blocks or site blocks to be used in the widgets editor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Widgets Screen The block-based screen that replaced widgets.php. Needs Dev Ready for, and needs developer efforts [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

9 participants