Skip to content

Themes: restore layout styles for block style variations with a block gap - #13398

Open
Jiwoon-Kim wants to merge 1 commit into
WordPress:trunkfrom
Jiwoon-Kim:fix/66044-variation-block-gap-layout-styles
Open

Themes: restore layout styles for block style variations with a block gap#13398
Jiwoon-Kim wants to merge 1 commit into
WordPress:trunkfrom
Jiwoon-Kim:fix/66044-variation-block-gap-layout-styles

Conversation

@Jiwoon-Kim

Copy link
Copy Markdown

Trac ticket: https://core.trac.wordpress.org/ticket/66044

Backport of WordPress/gutenberg#82335

Problem

A block style variation that declares spacing.blockGap emits 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'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:

if ( isset( $block_metadata['name'] ) ) {
	$block_type = WP_Block_Type_Registry::get_instance()->get_registered( $block_metadata['name'] );
	if ( ! block_has_support( $block_type, array( 'layout' ), false ) && ! block_has_support( $block_type, array( '__experimentalLayout' ), false ) ) {
		return $block_rules;
	}
}

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 base spacing.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: a core/paragraph variation declaring blockGap now emits nothing, where dropping the key entirely would produce rules for layout classes that block never carries.

Testing Instructions

npm run test:php -- --filter test_block_style_variation

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.

… 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.
@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown

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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props kimjiwoon.

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

@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown

Test using WordPress Playground

The 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

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant