-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Widget area discussion - should widget areas be blocks? #33254
Comments
A suggestion would be to only show one widget area at a time. That would mirror the way the customizer and the navigation editor work. I also feel that a downside of the current UI is that it requires a lot of scrolling. Especially if a theme has lots of widget areas or a user has added lots of blocks. |
I was thinking about #32952 yesterday and wondering if we could add the multi-entity save flow to the Widgets Screen and make the Widget Area block an This suggests to me that Widget Area should be a block, unless any React component can have an |
Using blocks makes it awkward for extenders: #32607 |
Reading this comment in 2022 made me think of the isolated template part editor. |
Using blocks means that we can't implement a Code Editor: #33518 |
Hmm, yeah, I guess Code Editor would have to be a widget area block feature. |
Using blocks makes it so that pressing Tab selects the sidebar and not the first block in the widget area: #38260 |
Using blocks leads to issues with copy/paste: #41284 |
I submitted a new issue #45398 with copy/paste. |
What problem does this address?
In the standalone widget editor, widget areas are currently blocks. They're implemented in a locked template, with unlocked inner blocks areas.
There are several areas where using a block wasn't ideal:
When you consider all of this, most of the block-y aspects of a widget area have been removed or disabled, so maybe they don't need to be blocks? What are the alternatives?
The text was updated successfully, but these errors were encountered: