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

Widget area discussion - should widget areas be blocks? #33254

Open
talldan opened this issue Jul 7, 2021 · 9 comments
Open

Widget area discussion - should widget areas be blocks? #33254

talldan opened this issue Jul 7, 2021 · 9 comments
Labels
[Feature] Widgets Screen The block-based screen that replaced widgets.php. [Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@talldan
Copy link
Contributor

talldan commented Jul 7, 2021

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:

  • Pretty much every feature on the block had to be disabled (reusable, html, custom classes etc.)
  • An experimental block supports property was added to hide the block toolbar
  • An experimental block supports property was added to hide the parent selector on child blocks
  • When a widget area is selected, a hack is in place to make the inspector show 'No blocks selected' and instead show a separate tab for details of the widget area.
  • The editor has some custom selection logic for inserting blocks into widget areas from the block library.

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?

@talldan talldan added [Feature] Widgets Screen The block-based screen that replaced widgets.php. [Type] Discussion For issues that are high-level and not yet ready to implement. labels Jul 7, 2021
@talldan
Copy link
Contributor Author

talldan commented Jul 7, 2021

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.

@noisysocks
Copy link
Member

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 EntityProvider (with sidebar as the entity) so that saving widgets uses the same infrastructure that the site editor uses.

This suggests to me that Widget Area should be a block, unless any React component can have an EntityProvider? (Not too familiar with how that stuff works.)

@noisysocks
Copy link
Member

Using blocks makes it awkward for extenders: #32607

@noisysocks
Copy link
Member

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.

Reading this comment in 2022 made me think of the isolated template part editor.

Screen Shot 2022-02-04 at 17 02 08

@noisysocks
Copy link
Member

Using blocks means that we can't implement a Code Editor: #33518

@talldan
Copy link
Contributor Author

talldan commented Feb 7, 2022

Hmm, yeah, I guess Code Editor would have to be a widget area block feature.

@noisysocks
Copy link
Member

Using blocks makes it so that pressing Tab selects the sidebar and not the first block in the widget area: #38260

@noisysocks
Copy link
Member

Using blocks leads to issues with copy/paste: #41284

@t-hamano
Copy link
Contributor

I submitted a new issue #45398 with copy/paste.

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. [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

No branches or pull requests

3 participants