Skip to content

BorderControl: Fix border controls rendering when only color or width is enabled#70869

Open
BugReportOnWeb wants to merge 4 commits intoWordPress:trunkfrom
BugReportOnWeb:fix/border-width-color-control
Open

BorderControl: Fix border controls rendering when only color or width is enabled#70869
BugReportOnWeb wants to merge 4 commits intoWordPress:trunkfrom
BugReportOnWeb:fix/border-width-color-control

Conversation

@BugReportOnWeb
Copy link
Copy Markdown
Contributor

What?

Closes #56402

This PR ensures that the rendering of border color and border width controls in the BorderControl component correctly reflects their respective settings.border.color and settings.border.width values.

Why?

Currently, the border UI in the editor shows both the color and width controls if either settings.border.color or settings.border.width is set to true in theme.json. This makes it impossible to:

  • Show only the color picker while keeping width fixed via default.
  • Show only the width input while disabling color control.

This behavior does not respect individual border settings and limits theme authors to control over the UI.

How?

  • Introduced new attributes showColorControl and showWidthControl in BorderControl and BorderBoxControl.
  • Updated the BorderPanel logic to pass these attributes based on the setting in theme.json.
  • Conditionally render the border controls based on these attributes.

Testing Instructions

  1. Create a theme or modify your theme.json:
{
  "settings": {
    "border": {
      "color": true,
      "width": false
    }
  }
}
  1. Open the block editor, insert a block that supports borders (e.g., Group).
  2. Go to the block settings and scroll down to the border settings.
  3. ✅ You should now only see the color picker (not the width input).
  4. Change theme.json to:
{
  "settings": {
    "border": {
      "color": false,
      "width": true
    }
  }
}
  1. ✅ Reload the editor, now only the width input should appear.
  2. If both color and width are true, both controls should appear as before.

Screenshots or screencast

Setting/View Linked Unlinked
Default Screenshot 2025-07-23 at 1 58 31 PM Screenshot 2025-07-23 at 1 58 41 PM
Only Color Screenshot 2025-07-23 at 1 57 17 PM Screenshot 2025-07-23 at 1 57 28 PM
Only Width Screenshot 2025-07-23 at 1 57 56 PM Screenshot 2025-07-23 at 1 58 06 PM

@BugReportOnWeb BugReportOnWeb marked this pull request as ready for review July 23, 2025 12:06
@github-actions
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: BugReportOnWeb <devasheeshkaul@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: skorasaurus <skorasaurus@git.wordpress.org>
Co-authored-by: dabowman <davidabowman@git.wordpress.org>

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

@github-actions
Copy link
Copy Markdown

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.

@im3dabasia im3dabasia added [Type] Bug An existing feature does not function as intended [Feature] Extensibility The ability to extend blocks or the editing experience labels Aug 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Feature] Extensibility The ability to extend blocks or the editing experience [Type] Bug An existing feature does not function as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Border width and color can't be individually disabled.

2 participants