Background: Fix the legacy gradient UI where a gradient cannot be selected - #81056
Conversation
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>
|
Size Change: +7 B (0%) Total Size: 7.78 MB 📦 View Changed
|
| const backgroundGradientSupported = | ||
| hasBackgroundSupport( name, 'gradient' ) && | ||
| !! settings?.background?.gradient; |
There was a problem hiding this comment.
This is the only change. As far as I've tested, the change to backgroundGradientSupported should not affect any other functionality.
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ramonjd
left a comment
There was a problem hiding this comment.
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
|
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. |
|
I'll look into the merge patch |
…ected (#81056) Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
|
This PR was backported to 7.1 by #81059 |
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.
settings.background.gradientvalue resolved fromtheme.json. When a theme sets it tofalse, the panel hides the new gradient control and renders the legacy one instead, which writes tostyle.color.gradient.background.gradientblock support.core/groupdeclares it, so the hook always expected the value atstyle.background.gradient.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.jsonsetting.Testing Instructions
background.gradientopt-out to your theme'stheme.json:{ "$schema": "../../schemas/json/theme.json", "version": 3, "settings": { "appearanceTools": true, "layout": { "contentSize": "840px", "wideSize": "1100px" }, "background": { "gradient": false } } }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.