Skip to content

Components Style: Clean up admin-scheme usage#75098

Open
SirLouen wants to merge 1 commit intoWordPress:trunkfrom
SirLouen:fix/deduplicate-admin-scheme-use
Open

Components Style: Clean up admin-scheme usage#75098
SirLouen wants to merge 1 commit intoWordPress:trunkfrom
SirLouen:fix/deduplicate-admin-scheme-use

Conversation

@SirLouen
Copy link
Member

Why?

Minor fix, during chore code analysis in the works of #75096 I noted that this was being duplicated unnecessarily,

How?

Simply importing the default styles and removing duplication.

@SirLouen SirLouen requested a review from youknowriad January 30, 2026 15:29
@SirLouen SirLouen self-assigned this Jan 30, 2026
@SirLouen SirLouen requested a review from ajitbohra as a code owner January 30, 2026 15:29
@SirLouen SirLouen added [Type] Code Quality Issues or PRs that relate to code quality [Package] Components /packages/components labels Jan 30, 2026
@github-actions
Copy link

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: SirLouen <sirlouen@git.wordpress.org>

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

@use "./validated-form-controls/style.scss" as *;

// Include the default WP Components color variables.
// TODO: Remove this once all admin-scheme variables are accounted for in the wp-components fallback values.
Copy link
Member

Choose a reason for hiding this comment

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

This comment seems to imply that we don't actually want this admin-scheme to be applied, that it should be achieved through fallback values in component styles. I feel like we're no longer setting an expectation of that goal with this refactor.

Copy link
Member Author

Choose a reason for hiding this comment

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

By adding default colors I'm assuming that as this new pattern grows expectations will be fulfilled by convenience, dont you think so?

Do you think that this still is going to hold any value for the future?

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess the point is that we want to make sure that the component package can be "independent" from being rendered in the wp-admin context, and therefore should have fallbacks for the --wp-admin-theme-* and --wp-admin-border-* variables?

Also, there's another consequence of deleting this code: AFAIK, the admin schemes in other parts of the codebase don't use the blueberry blue color (#3858e9) as the default primary color, right?

Copy link
Member

Choose a reason for hiding this comment

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

While I don't have a clear memory of this anymore, looking at the blame I can see that this PR is doing pretty much what I describe in the "🛠️ How to restore previous color scheme" section in the description of #50193. So I think we can confidently say it goes against the original intention of the code 😄

@aduth aduth requested a review from a team January 30, 2026 19:05
@SirLouen SirLouen removed their assignment Feb 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Package] Components /packages/components [Type] Code Quality Issues or PRs that relate to code quality

4 participants