Core Group Block: Missing "wp-block-group__inner-container" in block editor after updating to Gutenberg 10.3.0

[CreativeDive]

Hey,

after updating to Gutenberg 10.3.0 the "wp-block-group__inner-container" is completely removed if I'm in the block editor.

Please confirm this is a bug. The inner container is essential to restrict the max width of inner blocks.

This change totally breaks the layout.

[youknowriad]

No, this is not a bug, this is intentional. The idea is that we shouldn't have added this div in the first place, when you add a "group", you just need a div, there's no reason to use two divs. For backward compatibility, we kept the div in the frontend.

The idea is that for FSE themes, this div shouldn't be added even in the frontend.

What kind of layout breakage are you seeing?

[youknowriad]

We're considering restoring it in the editor as well for classic themes in #30453 depending on how important the breakage is

[nbatteur]

HI, On all my customer sites, the pages are completely blank on the front-end after a change with version 10.3.0. I had to roll back to the previous version to restore the front-end.

[youknowriad]

the pages are completely blank on the front-end after a change with version 10.3.0. I had to roll back to the previous version to restore the front-end.

Would you mind shared the content of one of your pages, that sounds like a different issue that we're not aware of?

[youknowriad]

Also, note that the Gutenberg plugin is a development plugin to ensure the new WordPress Core release is as stable as possible. So if you decide to use it in your customer's websites, you should be aware that potential breakage from time to time is possible even if we try to do our maximum to reduce the risks.

[nbatteur]

Here the code of a page:
legal_page.zip

[nbatteur]

Also, note that the Gutenberg plugin is a development plugin to ensure the new WordPress Core release is as stable as possible. So if you decide to use it in your customer's websites, you should be aware that potential breakage from time to time is possible even if we try to do our maximum to reduce the risks.

I know, but so far I have never had a problem.

[youknowriad]

@nbatteur just noting that I'm able to reproduce the issue, no fix yet, checking.

[CreativeDive]

@youknowriad It feels like Gutenberg is a playground for a lot of developers.

In the past I hated working with Gutenberg because essential changes were made all the time, while I'm working on my projects. One day I was very satisfied because it seemed that Gutenberg now has a stable base. I was now able to work with it very well.

But now, I'm not happy again. Another very essential change is there, again!

Do you can explain this change more detailed, please?

Why this is changed?

What is the differences like before?

What is the How-To for us to work with this change?

I think the essential changes comes from #29335

At #29335 I can see the sidebar panel "Layout settings". But this is not a part of the group block after updating to Gutenberg 10.3.0. Is this a feature for full site editing only?

What that means for other core blocks which use the "*__inner-container" class, like the "Cover block"?

I have worked out complete working CSS rules which works with selectors like "*__inner-container":

[class*="__inner-container"] > * {
	width: auto;
	max-width: calc( var(--contentWidth) - 4.5rem );
	margin-left: auto;
	margin-right: auto;
}

The "*__inner-container" container is an essential container for me, the restrict the max width of all inner blocks.
This works really fine for blocks like "Group block" or "Cover Block".

The "*__inner-container" container is already used by other "Core Blocks".

After updating to Gutenberg 10.3.0, all nested blocks of the "Group block" are displayed next to each other instead of one below the other.

Until now with using the [class*="__inner-container"] selector I could manage all inner blocks in a similar and easy way.

And now? There are differences between parent blocks like "Group block" or "Cover Block". Why?

[CreativeDive]

@youknowriad So many themes works with the [class*="__inner-container"] selector.

e.g. WordPress default themes like Twenty Twenty or Twenty Twenty-One.

Here only on example of the Twenty Twenty-One:

.has-background:not(.has-text-color).has-black-background-color[class] > [class*=__inner-container], .has-background:not(.has-text-color).has-gray-background-color[class] > [class*=__inner-container], .has-background:not(.has-text-color).has-dark-gray-background-color[class] > [class*=__inner-container] {
    --local--color-primary: var(--global--color-background, #fff);
    color: var(--local--color-primary, var(--global--color-primary));
}

I have prepared myself to always use this method in the future because all blocks that can contain inner blocks will use this container [class*="__inner-container"].

Now it has been worked on and a lot of themes has been optimized for it.

Now something fundamental is being changed again in the core blocks.

Should everyone deal with it again now?

@youknowriad Will this affect all core blocks in the future? Will the container *__inner-container be removed everywhere? Also in "Cover" or "Columns" block?

[ockham]

@CreativeDive -- @youknowriad is working on a fix, I'm trying to help along. I'll reply with more details once we know more; we can also discuss your questions later, but for now, we'll be focusing on fixing this issue.

[CreativeDive]

@ockham thanks for response.

But there is ONE BIG MAIN QUESTION here, for later after this issue is fixed.

What do we want in the end when Gutenberg is completely stable?

The most important thing is that all blocks that work in the same way should use the same markup.

This is the only way to optimize a theme uniformly.

If the *__inner-container container in the group block is now removed, there are again new differences. Other blocks like the "Cover block" still use this container.

In the end, the goal must not be that the markup of the "Group" and "Cover block" differ. Not even for all other blocks that use this container *__inner-container.

Will the container be removed everywhere in the future?

Backwards compatibility is good for now.

But I want to optimize everything to the default behavior of blocks.

So I ask, what will the future solution look like for all core blocks that contain inner blocks?

[jeremyfelt]

@youknowriad I believe @nbatteur's issue may be described by #30461, which is separate from this issue.

@nbatteur can you add a comment to #30461 with your PHP version if possible? (Tools -> Site Health -> Info -> Server).

[CreativeDive]

@youknowriad At the other point, there is something wrong with this new implementation from Gutenberg 10.3.0.

At the block editor the *__inner-container is removed:

But in the frontend the *__inner-container is still there.

Then I have deactivated Gutenberg 10.3.0 to default WordPress without Gutenberg Editor.

Then I refresh the frontend, and the *__inner-container is removed:

I can't understand the logic here.

[youknowriad]

Restored the inner div in #30453 and still working on the content loss in this issue #30461

@CreativeDive I'll circle back later here and explain more. There's also some related documentation coming in the release post (to be published later today or tomorrow), In the meantime, you can follow the discussions that happened in #29335 to learn more about the reasoning and the approach.

[CreativeDive]

@youknowriad thanks I will waiting.

Sometimes it seems necessary to make essential changes.

But what does that mean for all other core blocks with the *__inner-container?

No markup differences may remain in the future.

[youknowriad]

But what does that mean for all other core blocks with the *__inner-container?

It's a block per block discussion. Basically in the "group" block, the double div was not useful at all. It was introduced to allow some themes to define "wide/full" alignments properly but the reality is that you can define these alignments properly with just a single div. That's how FSE themes do without sacrificing the semantics of the markup and introducing an extra div.

The main premise here for FSE themes is that everything should be controlled by the blocks in a declarative way, CSS provided by themes is only necessary if you want to customize the look of some particular block or something but in general everything should be editable and customizable in blocks and global styles.

If you check this PR for instance WordPress/theme-experiments#233 the empty theme has been updated to rely on the new layout config, you can see how much CSS is removed by the theme and everything works as expected by default in both frontend and editor without any specific CSS.

The same idea applies to all blocks: themes shouldn't have to know the markup of the blocks to be able to make customizations, they can use global styles and all blocks should look exactly the same between editor and frontend but not markup changes are planned for blocks at the moment and anytime we do something like that we're trying our best to not break anything.

[ockham]

We believed we've fixed the content loss issue per #30460. We've just released version 10.3.1 of Gutenberg, which includes that fix, plus #30453. This new version should thus hopefully include fixes for all the problems described in this issue.