Feat: Remove default background from theme.json when applying solid color to Buttons

[yogeshbhutkar]

Fixes: #67055

What?

Issue Summary: As per the issue and my testing, it was found that when we apply a default gradient to the button using theme.json, the user becomes ineligible for changing the gradient to any solid color thereafter giving rise the bug mentioned in the issue.

Proposed Approach: Introduce a new class name that contains the background: none; property which can be applied whenever we have a backgroundColor.

Why?

This PR is necessary to resolve the bug mentioned above.

How? ( Approach )

Normally, the gradient is applied using the background property, if we generalize the background property in theme.json then this property gets applied by default to the buttons, when we change the background color, the backgroundColor property changes, but background property is still derived from the parent leading to this bug.

This approach adds background property as null to the button whenever a backgroundColor value is set. This way, the rest of the buttons can by default inherit the default background color from theme.json while allowing users to override it from the editor.

Testing Instructions

1. Override the default theme.json and add default gradient styles for button.

"button": {
        "color": {
            "text": "#fff",
            "gradient": "linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)"
        }
}

2. Create a post and add buttons to it.
3. Try to change the default gradient to any solid color, observe the color being changed on the editor.
4. Save the post and observe the change being reflected in the permalink of the post.

Screenshots or screencast

https://github.com/user-attachments/assets/9653cd62-0a0a-4f77-8b7f-95a839228263

https://github.com/user-attachments/assets/161dae4a-c3d8-4c0f-94de-7223e3a87bee

[github-actions[bot]]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions[bot]]

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: yogeshbhutkar <yogeshbhutkar@git.wordpress.org>
Co-authored-by: im3dabasia <im3dabasia1@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>

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

[yogeshbhutkar]

As per the suggestion provided by @carolinan, the PR is now enhanced to fix the bug across all the blocks. It's tested on a lot of blocks ( screenshot attached below ) and is found to work as expected.

The PR is ready to be reviewed.