Make WordPress Core

Opened 6 weeks ago

Last modified 6 days ago

#66026 assigned feature request

User Profile: Add option for custom admin color scheme

Reported by: aduth Owned by: aduth
Priority: normal Milestone: Awaiting Review
Component: Administration Version:
Severity: normal Keywords:
Cc: Focuses: ui, administration

Description (last modified by aduth)

Related: #65776

Task: Add a new "Custom" option to the Administration Color Scheme setting on the Users > Profile settings page that allows the user to select an accent color and sidebar background color to apply to their WordPress admin interface.

Context:

With the ​design system theming color tokens added in WordPress 7.1, one of the intended next steps from the original ​merge proposal is to explore "Enhanced user customization through theming".

There's a long-term ambition here to enable full configurability for customizing the entire WordPress admin interface, including the content area and "dark mode" themes. There have been ​some concepts for this as far back as 2022 and the ​"Admin Design" phase 3 overview.

What's proposed in this ticket is a smaller, incremental step that enables user customization and builds upon existing support for color schemes and design system theming.

Design Notes:

The attached image can give an idea of how it could be integrated into the existing settings. It is not a design proposal (I am not a designer) and I'd welcome design input on a final design.

Implementation Notes:

This would likely depend on (be blocked by) API improvements proposed in #65776.

This should also integrate with site editor improvements in r62454 (​Gutenberg#78397).

Generated styles for wp-admin interface elements may use parts of ​`@wordpress/theme`, either the ThemeProvider itself (React-based) or ​internal color ramp logic, which may require changes in the package to expose this as a generalized JavaScript utility not bound to React.

Attachments (2)

Screenshot 2026-09-02 at 11.20.49 AM.png​ (308.4 KB ) - added by aduth 6 weeks ago.
Profile page with new custom option
Screenshot 2026-09-02 at 11.20.37 AM.png​ (331.7 KB ) - added by aduth 5 weeks ago.
The Linear product development application can be a source of inspiration for how it presents user customization of accent and background colors in its sidebar and interface areas

Download all attachments as: .zip

Change History (7)

@aduth
6 weeks ago

Profile page with new custom option

#1 @aduth
6 weeks ago

  • Description modified (diff)

@aduth
5 weeks ago

The Linear product development application can be a source of inspiration for how it presents user customization of accent and background colors in its sidebar and interface areas

#2 @aduth
10 days ago

Generated styles for wp-admin interface elements may use parts of @wordpress/theme, either the ThemeProvider itself (React-based) or internal color ramp logic, which may require changes in the package to expose this as a generalized JavaScript utility not bound to React.

Related Gutenberg issue for plain JavaScript utility: ​https://github.com/WordPress/gutenberg/issues/84030

#3 @aduth
7 days ago

Generated styles for wp-admin interface elements may use parts of @wordpress/theme, either the ThemeProvider itself (React-based) or internal color ramp logic, which may require changes in the package to expose this as a generalized JavaScript utility not bound to React.

As far as how theming takes effect, I see a few options:

  • When the user makes a color preference change in the Profile settings page, the color ramp is generated at the time of save and persisted into user options. This has some performance advantage to generate the ramp once, at the trade-off of additional storage cost and risk of falling out of sync if the algorithm is improved.
  • Saving color preference saves the seed values, in a structure like what's discussed in #65776 . The color ramps are generated at page load time, similar to how ThemeProvider works in React-based pages. This is a relatively simple approach, enabled through ​GB#84030, but comes at the cost of computing color ramps every page load and potentially even a "flash of unstyled content" effect until the updated color styles are applied.
  • Like the second option above, we could store the seed values, but implement an alternative color ramp algorithm in PHP. This would allow the color ramps to be generated server-side before page load, but comes at both a performance cost at page load time and an additional maintenance overhead of maintaining multiple implementations.

Personally, my leaning is toward the second option, particularly given the alignment of behavior to ThemeProvider, and since we expect to improve the color algorithms over time. We could potentially offset the concerns by leveraging local browser caches (e.g. localStorage).

#4 follow-up: @fushar
6 days ago

Hi @aduth. I agree that this is a good incremental step to start using the DS theming in color schemes.

I just want to confirm that the "sidebar background" and "accent" color selections are meant to be seed, right? For example, the actual sidebar / admin bar background color will be generated by the color ramp algorithm based on the seed value. So, the actual color could be potentially different from what the user chooses. Would that be a bit confusing / unexpected from the user's perspective?

#5 in reply to: ↑ 4 @aduth
6 days ago

Replying to fushar:

I just want to confirm that the "sidebar background" and "accent" color selections are meant to be seed, right? For example, the actual sidebar / admin bar background color will be generated by the color ramp algorithm based on the seed value. So, the actual color could be potentially different from what the user chooses. Would that be a bit confusing / unexpected from the user's perspective?

Correct, they are seed values, and also correct that there's no guarantee that the color generated from the algorithm for static content backgrounds like the sidebar and admin bar are exactly the same as the seed color selected by the user (or specified by the plugin as in the case of #65776's proposed API).

That being said, the default value for the background surface in this case is the specified seed value by default (​source), and is only adjusted as needed if the rest of the ramp would otherwise not be able to achieve its contrast targets.

There's also a bit of ​related documentation in the package README:

The seed values guide the generated color ramps but are not guaranteed to appear unchanged in the resulting tokens. The ramp builder may adjust their lightness to meet its contrast targets.

So tl;dr is that the background would usually end up being the same as the seed value or close to it, but it's not a contractual guarantee that it's identical. I would imagine in most cases it should be perceptually similar enough so as not to be confusing from what was selected.

(cc @mciampini as having the most knowledge of the theme implementation details, in case there's anything to add or clarify)

Last edited 6 days ago by aduth (previous) (diff)
Note: See TracTickets for help on using tickets.