Site Editor: Apply the user's admin color scheme#78397
Open
fushar wants to merge 12 commits into
Open
Conversation
github-actions
Bot
added
[Package] Edit Site
fushar
force-pushed
the
admin-bar-in-editor-color-4
branch
from
0fc11f7 to
231eebb
Compare
|
Size Change: +953 B (+0.01%) Total Size: 7.98 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in f70d056. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26205624555
|
|
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. |
fushar
added
[Type] Feature
ciampo
reviewed
May 18, 2026
Contributor
There was a problem hiding this comment.
I'm not sure that "WordPress app" concerns (such as named theme presets) should live in the @wordpress/theme package, which is supposed to be focused on app-agnostic features and tokens.
Contributor
Author
There was a problem hiding this comment.
Interesting, I thought because admin color scheme is a core WP feature, it could belong in that package.
OK, I moved the logic to @wordpress/admin-ui instead via f733f13. I think that's a better place. What do you think?
Contributor
There was a problem hiding this comment.
admin-ui feels like a better fit given current constraints (dependency graph), although I don't know if it is the correct choice in general terms.
@wordpress/theme is app-agnostic, and focuses on tokens + theming primitives
Member
There was a problem hiding this comment.
I would say admin-ui is also not the best fit, since admin color schemes will be used in wider contexts (like post/page editors as well).
If we consider the future of the @wordpress/components package as a more higher-level package of things with explicit WordPress coupling, maybe @wordpress/components is actually a better place 😄
Contributor
Author
There was a problem hiding this comment.
Good idea; extracted getAdminThemeColors() and removed UserThemeProvider via 8180dde. Now we pass theme colors more explicitly.
I think admin-ui is good enough place for now. Post/Page Editors are by definition "admin" pages (wp-admin) as well 😄 unless I'm misunderstanding things.
fushar
force-pushed
the
admin-bar-in-editor-color-4
branch
4 times, most recently
from
ccce419 to
f733f13
Compare
jameskoster
reviewed
May 18, 2026
Contributor
|
Was also about to share similar feedback to @jameskoster re. using the correct tokens. The |
ciampo
reviewed
May 18, 2026
fushar
force-pushed
the
admin-bar-in-editor-color-4
branch
from
9c6817c to
32d2f18
Compare
aduth
reviewed
May 19, 2026
| import { getAdminThemeColors } from './admin-theme-colors'; | ||
|
|
||
| export const privateApis = {}; | ||
| lock( privateApis, { |
Member
There was a problem hiding this comment.
I'm not sure if it's an issue for the package itself or only its consumers (e.g. #75319), but my understanding is that private APIs don't get along very well with packages that are bundled by consumers rather than exposed as a window.wp global. I'd generally expect that these packages should just ship code and make breaking changes as needed rather than use the private API locking.
Contributor
Author
There was a problem hiding this comment.
TIL, thanks for the context. Removed here: 6dcd757
Contributor
Not sure if these screenshots are up to date, but I can see a small difference between the background gray color used in the sidebar and top bar, and the background used around the canvas (which replaced the previous black background). It's a small difference, but they're not the same color and now I can't unsee it 🙈 
|
Contributor
Author
Yes... this is how the design system works. Even though I pass the actual Core's admin bar background color to |
Member
To follow-up, I've proposed improvements to the |
Member
In fact, we could make a case for the opposite direction, where we tweak the Core admin schemes upstream so they match the design system colors? |
Contributor
The admin schemes in general deserve love and attention, and have deserved this for a long time. The nuance is, they deserve this so much that I would caution too much investment in it; as part of fresh work on this, I imagine reinvention of the scheme system entirely, retiring most schemes but instead providing a simple tool to pick just a color or two and have the scheme be generated from that. Instead of a "Coffee" color scheme, it's a brown color-swatch. This considers also dark and light modes, which could be a toggle that sat separately to color schemes, or were just color schemes on their own. Along the lines of this: 
The work in this PR does not preclude that from happening. I'm mostly putting it on the radar as something to consider for the future, so that the investment into the current system is measured against that. Is that fair? |
Contributor
|
I think a couple of minor hex value tweaks in order to significantly improve admin theme support in the site editor would be worthwhile. I agree admin themes in general need a fresh look but that's definitely something to explore separately. |
Member
Same! Thanks for taking on it @fushar. I'm a bit preoccupied to review in the next 2 weeks, but you're in good hands with the components team taking a look! |
Contributor
Author
Well that's what I've been trying to do the whole day 😄 what exactly do you think is still bad in the screenshots? Note that we can only tweak the seed and the color ramp will generate the color set. |
Contributor
Contributor
Author
It's not possible; I've tested it 🥲 the algorithm doesn't think that the exact wp-admin bg colors are good a11y-wise. And I think updating Core admin color schemes is beyond the scope of this PR 🤔 I have an alternative idea. What if we just drop the gutter if the page is rendered in a regular wp-admin page (non-site editor), by setting white bg color? This is the diff: diff --git i/packages/boot/src/components/root/style.scss w/packages/boot/src/components/root/style.scss
index 49e48a8680f..bd96e01142a 100644
--- i/packages/boot/src/components/root/style.scss
+++ w/packages/boot/src/components/root/style.scss
@@ -11,6 +11,10 @@
background: var(--wpds-color-bg-surface-neutral-weak);
}
+.boot-layout--single-page {
+ background: #fff;
+}
+
.boot-layout__sidebar-backdrop {
position: fixed;
top: 0;This will make it consistent with other wp-admin pages which don't have the chrome. Screenshot:
|
Contributor
As an experiment with the "light" theme featured in the screenshot above, I tried to manually tweak the 
Not ideal, but it may be the quicket solution for the sake of this PR: for each wp-admin theme, tweak the In the long term, I agree with @mirka that we should unify the source of truth for the color scheme hexes, and that should likely be Gutenberg (expanding into legacy UI) |
Contributor
Author
When I did the exploration I think it's not possible for darker schemes such as Sunrise. The ramp logic somehow decides that the background color is outside an allowed range so it keeps returning other colors. Just to be very sure, I'm trying to run a script to brute-force all 256^3 RGB seed combinations and check which one results in an exact match of background color for each color scheme. It will take a couple hours (or more); the |
fushar
force-pushed
the
admin-bar-in-editor-color-4
branch
from
6dcd757 to
f70d056
Compare
Contributor
Author
|
OK, I've run the following vibe-coded brute-force script (for 3 hours 😄) we can only achieve perfect match with The scriptimport { ColorSpace, sRGB, OKLab, to, parse } from 'colorjs.io/fn';
import { buildRamp } from './packages/theme/build-module/color-ramps/lib/index.mjs';
import { BG_RAMP_CONFIG } from './packages/theme/build-module/color-ramps/lib/ramp-configs.mjs';
ColorSpace.register( sRGB );
ColorSpace.register( OKLab );
const TARGETS = [
[ 'fresh', '#1d2327' ],
[ 'modern', '#1e1e1e' ],
[ 'midnight', '#363b3f' ],
[ 'coffee', '#7c726c' ],
[ 'ocean', '#5f787f' ],
[ 'blue', '#0e7da4' ],
[ 'ectoplasm', '#8468ab' ],
[ 'sunrise', '#cc4541' ],
[ 'light', '#e5e5e5' ],
];
const toOklab = ( hex ) => to( parse( hex ), OKLab ).coords;
const toHex = ( r, g, b ) =>
`#${ [ r, g, b ].map( ( x ) => x.toString( 16 ).padStart( 2, '0' ) ).join( '' ) }`;
const squaredDistance = ( [ l1, a1, b1 ], [ l2, a2, b2 ] ) =>
( l1 - l2 ) ** 2 + ( a1 - a2 ) ** 2 + ( b1 - b2 ) ** 2;
const targets = TARGETS.map( ( [ name, hex ] ) => ( {
name,
hex,
oklab: toOklab( hex ),
} ) );
const bestPerScheme = targets.map( () => ( {
squaredDistance: Infinity,
seed: null,
surface1: null,
} ) );
const startTime = Date.now();
for ( let r = 0; r < 256; r++ ) {
for ( let g = 0; g < 256; g++ ) {
for ( let b = 0; b < 256; b++ ) {
const seed = toHex( r, g, b );
let surface1;
try {
surface1 = buildRamp( seed, BG_RAMP_CONFIG ).ramp.surface1;
} catch {
continue;
}
const surface1Oklab = toOklab( surface1 );
for ( let i = 0; i < targets.length; i++ ) {
const sq = squaredDistance( surface1Oklab, targets[ i ].oklab );
if ( sq < bestPerScheme[ i ].squaredDistance ) {
bestPerScheme[ i ] = { squaredDistance: sq, seed, surface1 };
}
}
}
}
const pct = ( ( ( r + 1 ) / 256 ) * 100 ).toFixed( 1 );
const elapsed = ( Date.now() - startTime ) / 1000;
const eta = ( ( elapsed / ( r + 1 ) ) * ( 256 - r - 1 ) ).toFixed( 0 );
process.stderr.write( `\rR=${ r + 1 }/256 (${ pct }%) elapsed ${ elapsed.toFixed( 0 ) }s eta ${ eta }s ` );
}
process.stderr.write( '\n\n' );
for ( let i = 0; i < targets.length; i++ ) {
const best = bestPerScheme[ i ];
const deltaE = Math.sqrt( best.squaredDistance ).toFixed( 4 );
console.log(
`${ targets[ i ].name.padEnd( 10 ) } target=${ targets[ i ].hex } seed=${ best.seed } surface1=${ best.surface1 } ΔE=${ deltaE }`
);
}
Outputfresh target=#1d2327 seed=#25292b surface1=#1c2327 ΔE=0.0017 modern target=#1e1e1e seed=#222524 surface1=#1e1e1e ΔE=0.0000 midnight target=#363b3f seed=#3d4042 surface1=#333c42 ΔE=0.0064 coffee target=#7c726c seed=#9a9b97 surface1=#939689 ΔE=0.1091 ocean target=#5f787f seed=#82a0a2 surface1=#779b9e ΔE=0.1091 blue target=#0e7da4 seed=#1ca8d1 surface1=#529eba ΔE=0.1113 ectoplasm target=#8468ab seed=#a190d5 surface1=#9b8bcc ΔE=0.1048 sunrise target=#cc4541 seed=#fe6c63 surface1=#e4736a ΔE=0.1090 light target=#e5e5e5 seed=#eaeeed surface1=#e5e5e5 ΔE=0.0000 I've pushed a commit to update |
Contributor
Author
|
Here's how the background colors compare with Core's, using #77964 experiment:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Makes the Site Editor's sidebar and page shell (chrome) to follow the user's WordPress admin color scheme instead of always rendering a fixed dark barkground.
Why?
This is a continuation of #78331, as per the suggestion I made the changes directly via WPDS tokens +
ThemeProviderrather than overriding in the experiment SCSS file.How?
getAdminThemeColorsfrom@wordpress/bootto@wordpress/theme@wordpress/admin-ui, so both the Site Editor (@wordpress/edit-site) andbootcan share one implementation. It now also includes thebgcolor in addition toprimary. Previously,boothardcoded the sidebar background to#1d2327; it's now based on the admin color scheme.@wordpress/edit-sitenow passes theme colors toThemeProvider.edit-site's component SCSS files to WPDS tokens. I used trial-and-error with my AI agent until the token set looks good (check screenshot).Limitations
/wp-admin/admin.php?page=site-editor-v2) is EXCLUDED for now. The page does not add the color scheme to the<body>'sclass. I'm not sure if that's intended? It does work correctly on otherbootpages like Appearance -> Fonts.Testing Instructions
Test the Site Editor (v1) with various admin color schemes (set via Users -> Profile). Also test on various screen widths to test mobile behavior.
Test also
bootpages such as Appearance -> Fonts.Screenshots
Appearance -> Fonts
(Check the right and bottom sides; they now follow the background color instead of black.)
Site Editor
Use of AI Tools
I used Claude Code with Opus 4.7 to help replace the hardcoded colors with appropriate WPDS token variables.
cc: @lucasmendes-design