Skip to content

Background: Fix the legacy gradient UI where a gradient cannot be selected - #81056

Merged
ramonjd merged 1 commit into
trunkfrom
fix/background-gradient-setting-opt-out
Aug 3, 2026
Merged

Background: Fix the legacy gradient UI where a gradient cannot be selected#81056
ramonjd merged 1 commit into
trunkfrom
fix/background-gradient-setting-opt-out

Conversation

@t-hamano

@t-hamano t-hamano commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

What?

Follow up to #77279

When a theme opts out of the new gradient background in theme.json, the Background panel falls back to the legacy gradient UI. I noticed that selecting a preset there does nothing at all, so this PR fixes it.

background.mp4

Why?

The Background panel and the block inspector hook that saves the value were deciding "which gradient is this?" by two different rules.

With the setting disabled, the panel wrote to one place and the hook read from another. Finding nothing, the hook saved an empty value, and the gradient never made it onto the block.

How?

Make the hook use the same rule as the panel: the block support and the resolved theme.json setting.

Testing Instructions

  1. Add the background.gradient opt-out to your theme's theme.json:
{
	"$schema": "../../schemas/json/theme.json",
	"version": 3,
	"settings": {
		"appearanceTools": true,
		"layout": {
			"contentSize": "840px",
			"wideSize": "1100px"
		},
		"background": {
			"gradient": false
		}
	}
}
  1. Insert a Group block and open the Background panel in the inspector.
  2. Open the Gradient control and pick a preset.
  3. The gradient should be applied to the block, and it should persist after saving and reloading.

Use of AI Tools

Claude Code was used to locate the cause, write the fix and author the unit tests. All changes were reviewed by me.

The Background panel gates its gradient control on the resolved
`settings.background.gradient` value, falling back to the legacy
`color.gradient` control when a theme opts out. The block inspector hook
gated on the block support alone, so for a block that declares
`background.gradient` it kept reading `style.background.gradient` and
discarded whatever the legacy control wrote. Applying a gradient from the
UI left the block unchanged.

Gate the hook on the setting as well, so both sides agree on which path
owns the value.

Co-Authored-By: Claude <noreply@anthropic.com>
@github-actions github-actions Bot added the [Package] Block editor /packages/block-editor label Aug 2, 2026
@t-hamano t-hamano changed the title Background: Fix the legacy gradient control when a theme opts out of background.gradient Background: Fix the legacy gradient UI where a gradient cannot be selected Aug 2, 2026
@github-actions

github-actions Bot commented Aug 2, 2026

Copy link
Copy Markdown

Size Change: +7 B (0%)

Total Size: 7.78 MB

📦 View Changed
Filename Size Change
build/scripts/block-editor/index.min.js 428 kB +7 B (0%)

compressed-size-action

@t-hamano t-hamano added [Type] Bug An existing feature does not function as intended [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi Backport to WP 7.1 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta labels Aug 2, 2026
Comment on lines +202 to +204
const backgroundGradientSupported =
hasBackgroundSupport( name, 'gradient' ) &&
!! settings?.background?.gradient;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only change. As far as I've tested, the change to backgroundGradientSupported should not affect any other functionality.

@t-hamano
t-hamano marked this pull request as ready for review August 2, 2026 16:40
@github-actions

github-actions Bot commented Aug 2, 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.

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: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>

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

@ramonjd ramonjd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thanks for catching. As a reward, here are some videos

Before

Kapture.2026-08-03.at.09.47.44.mp4

After

Kapture.2026-08-03.at.09.45.39.mp4

@ramonjd
ramonjd enabled auto-merge (squash) August 2, 2026 23:50
@ramonjd
ramonjd merged commit 511df82 into trunk Aug 3, 2026
71 of 73 checks passed
@ramonjd
ramonjd deleted the fix/background-gradient-setting-opt-out branch August 3, 2026 00:10
@github-actions github-actions Bot added this to the Gutenberg 23.8 milestone Aug 3, 2026
@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 511df8215203a2c7b059864d4edf0ad764c972e6

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

@ramonjd

ramonjd commented Aug 3, 2026

Copy link
Copy Markdown
Member

I'll look into the merge patch

Comment thread packages/block-editor/CHANGELOG.md
ramonjd added a commit that referenced this pull request Aug 3, 2026
…ected (#81056)

Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
@ramonjd

ramonjd commented Aug 3, 2026

Copy link
Copy Markdown
Member

Merge patch:

@t-hamano

t-hamano commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

This PR was backported to 7.1 by #81059

@t-hamano t-hamano added Backported to WP Core Pull request that has been successfully merged into WP Core and removed Backport to WP 7.1 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta labels Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Backported to WP Core Pull request that has been successfully merged into WP Core [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi [Package] Block editor /packages/block-editor [Type] Bug An existing feature does not function as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Sponsor
SponsoredKunjungi sekarang
Promo