[adamwoodnz]

What?

Closes #83748

Changes the :root default for --wp-admin-theme-color in @wordpress/base-styles from the legacy #007cba to #3858e9, the WordPress 7.0 default admin color scheme.

Why?

WordPress 7.0 made the Modern scheme the default and moved existing users to it (Trac #64546, r61644). @wordpress/components already defaults to #3858e9 (#50193). The shared :root default in base-styles still sets #007cba, and most packages include it (block-library, block-editor, editor, edit-site, and others). Outside wp-admin (Storybook, standalone apps), whichever of those stylesheets loads after components resets the accent to #007cba. Jetpack's Storybook currently works around this with its own override (Automattic/jetpack#52849).

How?

• _default-custom-properties.scss: admin-scheme(#007cba) becomes admin-scheme(#3858e9).
• _mixins.scss: the link-reset focus fallback matches the new default.
• _mixins.scss: wordpress-admin-schemes() gets a body.admin-color-fresh rule with #007cba. Fresh had no rule and took the :root default, so without this, wp-admin screens that have no ThemeProvider (for example the Dashboard) would turn Fresh users' primary buttons blueberry. The value matches admin-ui's Fresh mapping (packages/admin-ui/src/admin-theme-colors/index.ts).
• _default-custom-properties.scss: the same Fresh rule follows the :root block. Plugins such as WooCommerce compile these defaults into their own CSS while the installed WordPress supplies admin-schemes.css, which on older versions has no Fresh rule. Shipping the rule with the defaults keeps Fresh on #007cba in that mixed-version case.
• var(--wp-admin-theme-color, #007cba) fallbacks in block-editor (global styles inheritance), editor (Style Book), and media-editor (cropper) become #3858e9, so the fallback matches the default everywhere.
• Changelog entry, including how to keep the old color.

The light scheme in wordpress-admin-schemes() keeps #007cba: that is the scheme's own color.

Testing Instructions

1. npm run build.

2. In packages/block-library/build-style/common.css, the :root rule sets --wp-admin-theme-color: #3858e9 and --wp-admin-theme-color--rgb: 56, 88, 233.

3. npm run storybook:dev (it starts its own watch build). Gutenberg's Storybook shows no visible change: its WithDesignSystemTheme decorator sets --wp-admin-theme-color inline on <html>, and that hides the stylesheet default. To see the default, open Editor / Block Editor / Inserter / Quick Inserter in the canvas iframe and run this in the console:

   document.documentElement.style.removeProperty( '--wp-admin-theme-color' );
   getComputedStyle( document.documentElement ).getPropertyValue( '--wp-admin-theme-color' );

   This branch returns #3858e9. Production Storybook (trunk) returns #007cba.

4. npm run wp-env start (this repo's .wp-env.json mounts the checkout as the plugin), and log in at http://localhost:8888/wp-admin with admin / password. In Users → Profile, check each scheme on the Dashboard (the "Publish" button in Quick Draft) and in the block editor (the "Publish" button):

   Scheme	Expected
   Default (Modern)	#3858e9
   Fresh	#007cba, the same as trunk
   Ocean	#567958

   Check Fresh on the Dashboard. The block editor sets the scheme color inline through ThemeProvider, so the editor does not show a regression there.

Verified on 48739714e3 (rebased on 05f1759ea6, after npm ci): npm run build, npm run lint:css, and npm run lint:js pass, and common.css has the values in step 2. In wp-env, the Publish buttons on the Dashboard and in the editor are #3858e9 for Modern, #007cba for Fresh, and #567958 for Ocean. For Fresh, I also removed the rule from wp-base-styles to simulate an older WordPress admin-schemes.css: the Dashboard stays #007cba, and turns blueberry only when the package copies are removed too. Before the rebase, the Fresh Dashboard matched trunk (26338bff28, built and checked in the same environment), and the step 3 console check returned #3858e9 locally and #007cba in production Storybook.

Testing Instructions for Keyboard

N/A: no UI change beyond the default accent color.

Screenshots or screencast

N/A

Use of AI Tools

Authored with Claude Code (Claude Opus 5.5): source investigation, the change, and this description.

[github-actions]

🤖 PR meta 🤖

👋 Welcome

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @adamwoodnz! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[github-actions]

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: adamwoodnz <adamwood@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>

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

[jasmussen]

Yes, this seems an oversight. Please await any input from Lena, also pinged, there could be nuance, but otherwise let's definitely go.

[mirka]

Can we also include the body.admin-color-fresh rule in this stylesheet (with a comment explaining why)?

The addition to wordpress-admin-schemes() preserves Fresh when both stylesheets update together, as they do when installing this Gutenberg PR. But plugins can compile default-custom-properties into their own CSS while relying on WordPress to supply the admin-scheme stylesheet. For example, EditorsKit imports these defaults in its Styles Manager styles, and WooCommerce imports them in its shared build styles.

If such a plugin rebuilds with the updated base-styles package, its CSS gets the Blueberry root default, but the installed WordPress version may still supply a scheme stylesheet without the new Fresh rule. Fresh previously inherited the old blue from :root, so it now inherits Blueberry instead. Plugins using only WordPress-provided styles would not have this mixed-version issue.

I reproduced that color change in an isolated browser check using the compiled defaults alongside WordPress 6.9 and 7.0's shipped CSS. Including body.admin-color-fresh { @include mixins.admin-scheme(#007cba); } here restored the original color.

Keeping the Fresh rule in both places would make the protection travel with independently bundled defaults, while standalone apps without the Fresh body class still get Blueberry.

I think this is necessary to keep this PR in "enhancement" territory and not a breaking change.

[adamwoodnz]

Good catch, thanks. Added in 4873971: body.admin-color-fresh { @include mixins.admin-scheme(#007cba); } now follows the :root block in _default-custom-properties.scss, with a comment on why. The rule stays in wordpress-admin-schemes() too, and the changelog entry covers both.

Verified in wp-env with the Fresh scheme on the Dashboard. I removed the Fresh rule from wp-base-styles in the page to simulate an older WordPress admin-schemes.css. The primary button stays rgb(0, 124, 186), because the rule now also ships in the commands, block-editor, patterns, and editor stylesheets. When I also removed those copies, it turned rgb(56, 88, 233). The editor with Fresh is also #007cba.

[adamwoodnz]

Also I'm unable to re-run the failing CI checks, which I believe are unrelated. Would you be able to do that for me please?

[mirka]

Two separate CI issues were fixed on trunk, so I merged them in 👍

[adamwoodnz]

Thanks!