Widgets: Add a 'Widget Box' container block

[ddryo]

I am testing the new Widgets Editor at 5.8 beta-2.

Now, I have set up the sidebar in my theme as follows.

register_sidebar(
    array(
        'name'          => 'Sidebar',
        'id'            => 'sidebar-1',
        'before_widget' => '<div id="%1$s" class="c-widget %2$s">',
        'after_widget'  => '</div>',
        'before_title'  => '<div class="c-widget__title">',
        'after_title'   => '</div>',
    )
);

We then have the following CSS applied to .c-widget and .c-widget__title.

.c-widget {
    border: solid 1px #000;
    padding: 1rem;
}
.c-widget__title{
    background: #000;
    color: #fff;
    margin: -1rem -1rem 1.25rem;
    padding: .5em;
}

For example, if I have a "Text" widget and a "Category" widget in place, it would look like this

The theme unifies the design of widgets placed in the sidebar.

Problem

In the new Widgets Editor, I cannot recreate the structure of .c-widget > .c-widget__title in blocks unless you use "Legacy Widgets" block.

Therefore, it is not possible to place new widgets using this unified design in blocks.

Try-1

If I try to use a heading block to place a title, it will look like this

Try-2

I added the .c-widget__title class to the heading block from the editor.

Try-3

Use a "Group" block and place "Heading" and "Paragraph" inside. Then, give the Heading a .c-widget__title class.

OK, I finally managed to place the widgets in the same design as before.

However, it is very time-consuming when you just want to place widgets "as before".

I find this to be a very important issue.

Will I have to enforce this procedure on the users of the theme in the future?

---

This is also related to issue #29019, but I've created a new topic to re-organize the issue.

[ddryo]

This is due to the following structural problems

[noisysocks]

Hi @ddryo. Thanks for the explanation and excellent diagrams. It will help to contain conversation about this to one issue thread so I'll close #29019 in favour of this one.

Re-sharing what you wrote in #29019 (comment):

For example, how about implementing a block that can be titled with a name like "Widget Box"?

Then, within the block editor of the widget area, limit the number of blocks that can be placed directly under the area to only two.

And in the block editor of the widget area, limit the number of blocks that can be placed directly under the area to two: the "Widget Box" block and the "Legacy Widget" block.

Of course, the "Widget Box" block is an inner block that can be placed freely.

I think this is a neat idea and might be the best way forward.

Some questions:

• How does Widget Box differ to a Group block?
• Does Widget Box have to have a "title" or does adding a Heading block to a Widget Box block suffice?
• Could Widget Box be a block pattern consisting of a Group and a Heading block?

None of this is particularly difficult to implement as all of the underlying infrastructure is available already. We will need to think through the design and UX considerations, though, by creating a prototype and testing it with the design team cc. @critterverse.

This will take a little bit of time and I am concerned that we do not have enough of it before the WP 5.8 RC 1 code freeze on June 29. Could this enhancement wait until 5.8.1 or 5.9?

[talldan]

This will take a little bit of time and I am concerned that we do not have enough of it before the WP 5.8 RC 1 code freeze on June 29. Could this enhancement wait until 5.8.1 or 5.9?

It does seem fairly late for the release process.

A pattern seems like a reasonable option, though the widgets screens don't seem to support them currently.

I could also see users needing a way to wrap a block already inserted. Maybe an option like the Group option, or a transform.

[ddryo]

@noisysocks

Some questions:
How does Widget Box differ to a Group block?
Does Widget Box have to have a "title" or does adding a Heading block to a Widget Box block suffice?
Could Widget Box be a block pattern consisting of a Group and a Heading block?

Here are my thoughts.

Point 1

The most important point is that the "Widget Box" should be prepared separately from the Group Block.

This is because their roles are distinctly different.

Currently, all blocks are automatically wrapped in .widget_block, but I would like to make this a block in itself.

For example, the structure of a "Widget Box" block would look like this

div.wp-block-widget-box (.widget_block)
    L div.wp-block-widget-box__titile
    L div.wp-block-widget-box__content
        L ( Inner Blocks )

(.wp-block-widget-box__content may be better without it, as it is closer to the structure of the existing widgets)

Written in block form, it looks like this

<div {...blockProps}>
    <RichText />
    <div {...innerBlocksProps} />
</div>

Point2

You need a "title". This is what makes sense.
It would be better if the output tag could be selectable like the "Heading" block, or rewritten with a hook. (I think the default is the div tag.)

Point3

I don't think it makes sense to have a block pattern consisting of a Group and a Heading block.

It is important to make the design of the widget consistent throughout the site. (As we have been able to do so far.

Translated with www.DeepL.com/Translator (free version)

[ddryo]

• I think we should quit automatically wrapping the blocks placed directly under the widget area with .widget_block.
• And "instead", I think we should allow the user to place the "Widget Box" block at will.
• And it should ideally be able to output a title.

[ddryo]

I would also like to add the disadvantage of having the blocks in the widget area automatically wrapped with .widget_block.

1. First of all, this is unpredictable when a user edits a block.
   Users who don't have access to developer tools will be very confused as to why the content doesn't look the way they want.

   For example, you might think you have two simple "paragraph" blocks, but each one is wrapped in a div. In addition, there may be a design applied that you don't remember. (Like the .c-widget shown at the beginning of this article, the)

2. The limitation of auto-wrapping severely reduces the flexibility of the block-based functionality that was evolved to allow free placement of content.

   This also feels out of sync with what FSE is trying to achieve, and feels half-baked.
   (I feel that the "freedom to place anything" itself is unnecessary in the traditional Themes...)

Translated with www.DeepL.com/Translator (free version)

[ddryo]

Let me add an additional explanation for my opinion that "it's not a good idea to implement this in a Block Pattern".

• Yes, it may be possible to implement the same thing with the block pattern, but it is not smart to have groups inside .widget_block(which in my case also has .c-widget), because it would output too much useless HTML.

• "Group" and "Heading" are too generic and can easily break the design depending on the settings.
  For example, color settings, font size settings, etc.

• The most important thing to remember is that "Legacy Widgets" are here to stay.
  This means that the .c-widget > .c-widget__title structure will remain. (Class names such as .c-widget will vary depending on the theme)
  When implemented in a Block Pattern, we will not be able to keep the same class structure, and we will have to add similar CSS to differently structured HTML to reproduce the same design.

• And there is one big problem. That is that too few users are using the Block Pattern.
  I've developed several themes and plugins, and there are many users who are not even aware of the Block Pattern.

Translated with www.DeepL.com/Translator (free version)

[justintadlock]

See: #25174

[draganescu]

While a block widget wrapper that somehow preserves the structure of widgets for blocks is a cool idea (be it with patterns, be it with a new block), it is not a given. This should be explored, but it is not a blocker for landing the widgets editor in WordPress 5.8 simply because all legacy widgets are fine.

Managing to get blocks to look like the theme's sidebar content is indeed a lot more complicated without this widget structure. On the other hand users have options to style blocks which classic widgets forms did not provide, hence there was much more need for convention on wrapper for that kind of content.

[ddryo]

@draganescu
I'm sorry.
I am Japanese and not a native speaker of English, so I could not understand your opinion exactly.

Could you please be more concise?

[draganescu]

Howdy @ddryo ! Briefly I believe we should mitigate the problems of widget and block wrappers, but it is not a blocker for the widgets updates in WordPress 5.8. That's all :)

[ddryo]

@draganescu
Thank you very much. I understand now.

However, this is a very important and critical issue, if we release it in 5.8 in a vague way, won't it cause even bigger confusion later?

If you feel that this is an issue that needs to be thought about a little more, I think we should think long and hard about it now, even if it means extending the blocking of the widget area first.

[ddryo]

I would like to raise one additional important issue.

It is about the use of "Column blocks".

There are many cases where you want to display multiple columns of widgets, for example in a footer widget area.

Until now, many themes have done this by providing multiple widget areas.

However, with the new block-based widget feature, you can use "column blocks".

I was very excited about that.

I was really looking forward to it, because it would allow me to create a variety of layouts with just one widget area.

However, the current specification is not what I had in mind.

The problem

What I had in mind was to be able to build a layout like the following.

However, in reality, the output has the following structure.

I'll try to explain how this is a problem in a bit more detail.

Concrete example

Place the two "Legacy Widget" blocks inside a "Columns" block in the editor as follows

At this point, the output I envision is as follows

But in reality, it will look like this

It seems that the title of Legacy Widgets without Columns is not given a .c-widget__title, but h2.widgettitle.

(Even if the .c-widget__title is given correctly, it will break the design.)

Instead of using Legacy Widget blocks in the Columns, I will use "Heading" blocks, "Categories" block, and "Archives" block, and add the .c-widget__title class to the Heading blocks by myself.

The result will look like this

As you can see, the design was broken even when using blocks.

Translated with www.DeepL.com/Translator (free version)

[ddryo]

@draganescu

I understand that being blocked will give me more freedom.

I am very excited about it.

But if that is the case, I don't understand why all blocks are automatically wrapped by .widget_block(which in my case also has .c-widget).

If we are going to get rid of the widget title feature for more freedom, I think the auto-wrap feature is getting in the way. (See the problem with the Columns block shown above.)

Even if the "Widget Box" block implementation is put on hold, I think that wrapping it in .widget_xxx(.c-widget) is sufficient only for "Legacy Widget" blocks.

[getdave]

Just to update here. We've been exploring two routes:

1. Block Pattern for "Widget + title".
2. A new "Widget Box" (working title) block.

Feedback one/both approaches would be much appreciated.

[getdave]

Update - pattern-based approach is a "no go"

Following lots of discussion and experimentation we've discovered that the pattern based approach is a "no go".

Therefore, we're going to proceed with a new block, but this will be renamed to "Widget Group" ("Box" was always a working title 😄 ) and refined so as to provide the best possible experience.