Layout: Skip outputting base layout rules that reference content or wide sizes if no layout sizes exist

[andrewserong]

What?

Fixes #60413

If the global theme JSON settings for settings.layout.contentSize or settings.layout.wideSize aren't set, skip outputting base layout styles that reference the CSS variables for those values.

Why?

As reported in #60413, when you add a wide block as a child of a Group block in a classic theme such as Twenty Twenty, then the layout support's constrained max-width styles wind up overriding the theme's styles for .alignwide. And since there are no content or wide size CSS variables available, this effectively results in wide size blocks being displayed as full width to their container.

With the approach in this PR, the output of the max-width rules that reference the CSS variables is skipped if there is no content or wide size value available, which should result in the bug being fixed for themes such as Twenty Twenty. Block themes that set content or wide size should be unaffected.

How?

In the Theme JSON class, skip output of base style rules that reference either of the content/wide size CSS variables if there is no content or wide size value available.

Testing Instructions

Activate Twenty Twenty theme and add the following test markup from #60413 to a post:

<!-- wp:group {"align":"full","backgroundColor":"primary","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull has-primary-background-color has-background"><!-- wp:paragraph {"align":"center"} -->
<p class="has-text-align-center">Full group.</p>
<!-- /wp:paragraph -->

<!-- wp:group {"align":"wide","backgroundColor":"accent","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignwide has-accent-background-color has-background"><!-- wp:paragraph {"align":"center"} -->
<p class="has-text-align-center">Wide group.</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

Save and publish the post. On the site front end, prior to this PR, the wide group block will extend to the full width of its container. With this PR applied, its max-width should be that provided by the theme (in the case of Twenty Twenty, it's 120rem).

To test against regressions, switch to a block theme and make sure that constrained layout works as expected in the post and site editors and on the site front end.

Screenshots or screencast

Before

Note how the base layout rules are overriding rules:

After

The base layout rules for max-width are no longer output:

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: andersnoren <anlino@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[andrewserong]

Just switching this over to Draft — there are some tests to update, and we might also want to include the same logic in the site editor's JS version of global styles 🤔

[tellthemachines]

Thanks for the PR! This change LGTM as is (not taking into account the pending test updates of course 😅 )

I think adding this logic to the JS global styles output can be considered as a follow-up, because it's existing behaviour (the regression we need to fix was caused by the layout classnames changing places in classic themes only) and it doesn't seem to have caused problems in block themes so far, maybe because when the theme doesn't define content widths the wide/full align options aren't available to blocks. So let's try it by all means, but I think it's better to keep this fix small as it's meant to go into the next minor release.

[andrewserong]

So let's try it by all means, but I think it's better to keep this fix small as it's meant to go into the next minor release.

Good thinking! Agreed. Let's go for the small change in this PR for 6.5.1, and we can explore the JS changes separately if need be 👍

I'll proceed with updating the tests.

[andrewserong]

I've updated the tests, and I've started a draft backport PR in core over in: WordPress/wordpress-develop#6362 — I ran out of time to finish that off today, but I'll continue on with it on Monday.

For now, I'll merge this PR in. Thanks again for the review!

[andrewserong]

Apologies everyone, I clicked merge too quickly and forgot to add in the props 🤦

Thanks again for the bug reports, triage, and reviews, everyone!

[ramonjd]

I just cherry-picked this PR to the release/18.1 branch to get it included in the next release: d639f38