Themes: restore layout styles for block style variations with a block gap - #13398
Themes: restore layout styles for block style variations with a block gap#13398Jiwoon-Kim wants to merge 1 commit into
Conversation
… gap. A block style variation that declares `spacing.blockGap` emitted no layout CSS at all in 7.1 -- not only the gap, but the flow, constrained, flex and grid rules together. 7.0 emitted them. `get_block_nodes()` stores the variation slug as the node's `name`. That array reaches `get_layout_styles()` as `$block_metadata`, where `name` is read as a block name and looked up in the block type registry to check for layout support. A variation slug is never a registered block, so the check fails and the method returns before generating anything. The metadata passed to `get_layout_styles()` now names the block the variation belongs to, at both call sites: the base `spacing.blockGap` and the one inside a viewport breakpoint, which takes its own copy. The variation node keeps its own slug, so feature-selector processing is unaffected, and the layout support check is answered against a real block rather than skipped. Three tests cover the base gap, the responsive gap inside its media query, and that a block without layout support still emits nothing. Props kimjiwoon, ramonopoly. Fixes #66044.
|
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 Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
Trac ticket: https://core.trac.wordpress.org/ticket/66044
Backport of WordPress/gutenberg#82335
Problem
A block style variation that declares
spacing.blockGapemits no layout CSS at all in 7.1 — not only the gap, but the flow, constrained, flex and grid rules together. 7.0 emitted them. There is no error; the spacing silently falls back to whatever the theme or Core sets globally.get_block_nodes()stores the variation slug as the node'sname. That array reachesget_layout_styles()as$block_metadata, wherenameis read as a block name and looked up in the block type registry to check for layout support:A variation slug is never a registered block, so the check fails and the method returns before generating anything.
Fix
The metadata passed to
get_layout_styles()now names the block the variation belongs to, at both call sites: the basespacing.blockGap, and the one inside a viewport breakpoint, which takes its own copy of the metadata.The variation node keeps its own slug, so feature-selector processing is unaffected, and the layout support check is answered against a real block rather than skipped.
get_layout_styles()itself is untouched — its guard is correct for real block nodes, and giving it the owning block name is what lets it do its job: acore/paragraphvariation declaringblockGapnow emits nothing, where dropping the key entirely would produce rules for layout classes that block never carries.Testing Instructions
Three tests: the base gap, the responsive gap inside its media query, and the layout support check. The first two fail without the change.
Manually, in a block theme add
styles/blocks/buttons-connected.json:{ "version": 3, "title": "Connected", "slug": "connected", "blockTypes": [ "core/buttons" ], "styles": { "spacing": { "blockGap": "var:preset|spacing|25" } } }Add a Buttons block with two buttons, apply the Connected style, and inspect the container on the front end. Expected: a gap rule for the variation. Before the change: none.