Frontend admin toolbar not using updated admin color scheme

[huzaifaalmesbah]

On the frontend, the admin toolbar menu is not using the updated Admin Reskin color scheme.

The toolbar menu item still appears with the old color on hover.

For visual consistency, the frontend admin toolbar should use the updated admin design tokens and color scheme so that it matches the rest of the admin interface.

Steps to reproduce:

1. Log in to WordPress.
2. Visit the frontend of the site.
3. Observe the admin toolbar menu styling.

Expected behavior:

The frontend admin toolbar menu item should follow the updated Admin Reskin color scheme for consistent UI across admin and frontend views.

[sabernhardt]

The front end intentionally did not use colors from the administration color scheme, and the $_wp_admin_css_colors variable is not available. See #26021 and #43742.

That is awkward now, after the default scheme changed within the admin area, but it was a decision.

If it is worth editing only for the Modern scheme, WP_Admin_Bar::initialize() theoretically could have something like this between enqueuing the admin-bar style and do_action( 'admin_bar_init' );.

if ( ! is_admin() ) {
	global $wp_version;

	$user_color = get_user_option( 'admin_color' );
	if ( isset( $user_color ) && 'modern' === $user_color ) {
		$suffix  = is_rtl() ? '-rtl' : '';
		$suffix .= SCRIPT_DEBUG ? '' : '.min';

		wp_enqueue_style(
			'admin-bar-admin-color',
			admin_url( "css/colors/modern/colors$suffix.css" ),
			array(),
			$wp_version
		);
	}
}

(I'm not sure whether it should check whether the user is logged in or any other conditions.)

[johnbillion]

I've never understood or agreed with the reasons given in #26021 against using the admin colour scheme for the admin toolbar on the front end.

• Arguments about colour clashes are moot. There are plenty of dark themes that clash with the toolbar, and light/dark colour schemes are prevalent.
• Extra assets. The front end toolbar already loads admin-bar.css and dashicons.css. An extra stylesheet for the colour scheme is inconsequential compared to the 1,000+ lines of inline CSS output by the editor.

If we're going to facilitate the Modern colour scheme (which has been renamed to Default in 7.0) on the front end then we might as well facilitate all the available colour schemes.

I think for 7.0, support for the modern colour scheme must be added. Support for all other colour schemes can either come for free as part of that, or if there's still opposition then that can come at a later date.

[noruzzaman]

I think we should support all admin color schemes for the frontend toolbar. Currently, when a user changes the color scheme, the dashboard and the frontend toolbar look different. This creates an inconsistent experience and does not look good visually. Supporting the same color schemes on the frontend toolbar would make the UI more consistent across both the dashboard and the frontend.

[JeffPaul]

I concur with @johnbillion, it seems odd to be in the admin and have one set of colors/fonts/etc and then when you view the frontend of the site to potentially have a totally different set within the same adminbar. Aligning the frontend to the new admin color scheme feels like a step in correcting this odd UX.

[joedolson]

I agree with @johnbillion and @jeffpaul. Supporting the admin color scheme should apply to everything that's part of the admin, including the adminbar.

Enqueue the user's selected admin color scheme CSS for the toolbar on the front end to ensure visual consistency with the admin dashboard.

Trac: https://core.trac.wordpress.org/ticket/64762

## Changes

• Registers admin color schemes on the front end if not already available.
• Enqueues the user's color scheme CSS with admin-bar as its sole dependency.
• Supports all registered admin color schemes.
• Schemes without a CSS URL (e.g., Fresh) gracefully fall back to base styles.

## Testing Instructions

1. Log in to WordPress.
2. Go to Users → Profile and select different color schemes.
3. Visit the frontend.
4. Expected: The toolbar matches the selected color scheme.

​https://github.com/user-attachments/assets/362f6e99-ad7b-4ecd-bc8f-f083182ffe0d

[amesplant]

@huzaifaalmesbah overall, this looks like a solid solution. I left some comments in your PR for you to review.

[sabernhardt]

Arguments about colour clashes are moot. There are plenty of dark themes that clash with the toolbar, and light/dark colour schemes are prevalent.

Clashes can occur because the color scheme stylesheets contain many rules in addition to the toolbar styles, including common elements that the theme might not override:

body,
a,
a:hover,
a:active,
a:focus,
input[type=checkbox]:checked,
input[type=radio]:checked,
input[type=text]:focus,
input[type=password]:focus,
input[type=color]:focus,
input[type=date]:focus,
input[type=datetime]:focus,
input[type=datetime-local]:focus,
input[type=email]:focus,
input[type=month]:focus,
input[type=number]:focus,
input[type=search]:focus,
input[type=tel]:focus,
input[type=time]:focus,
input[type=url]:focus,
input[type=week]:focus,
select:focus,
textarea:focus,
input[type=checkbox]:focus,
input[type=radio]:focus

My earlier suggestion in comment:2 also would have had that problem.

I'll add a pull request that tries to trim the stylesheet and add it as an inline style.

Adds CSS from admin color scheme stylesheets on the front end, as an inline style.

• Uses a separate function, which can be removed from the admin_bar_init action (and possibly deprecated later if stylesheets are replaced with CSS custom properties, etc.).
• Updates PHPUnit test.

Props: huzaifaalmesbah

Trac 64762

Use of AI Tools: none (by me)

Built with code from #11183

Looks good to me, and we got the expected result.

​https://github.com/user-attachments/assets/bfba1fb5-c5ba-47d8-ae9d-4bb8de7fda7e

[r1k0]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11192

Environment

• WordPress: 7.0-beta3-20260306.170257
• PHP: 8.3.30
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 145.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. Log in to the admin dashboard.
2. Visit the frontend.
3. Observe the color of the admin toolbar ( with different Admin color schemes).
4. ✅ Patch is solving the problem.

Expected result

• The admin toolbar now matches the chosen admin color scheme.

Additional Notes

• None

Screencast with results

Before:
​https://files.catbox.moe/jpqf8o.mp4
After:
​https://files.catbox.moe/6kyw6j.mp4

[shailu25]

Test Report

This Report Validates that the indicated patch address the issue.✅

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11192

Environment:

WordPress - 7.0-beta3-20260308.055323
OS - Windows
Browser - Chrome
Theme: Twenty Twenty Five
PHP - 8.2
Plugin - None

Actual Results:

• Issue Resolved with Patch ✅

Supplemental Artifacts

Before Patch: ​https://drive.google.com/file/d/1KXC9_Pok5wgP5rbJlCGAIILhqArMfSl2/view

After Patch: ​https://drive.google.com/file/d/1z9l2IBV1Ry4jGDyDiNb85LjdMveNCN2z/view

[sabernhardt]

@SergeyBiryukov Please check how I edited the unit test.

[audrasjb]

Thanks for the PR @sabernhardt.
The unit test edits look good to me.

[audrasjb]

In 62025:

Toolbar: add CSS from admin color scheme on front-end.

This changeset introduces the wp_admin_bar_add_color_scheme_to_front_end() which is hooked on admin_bar_init in order to use the CSS from admin color schemes on the admin bar on front-end, as inline styles.

Props sabernhardt, huzaifaalmesbah, audrasjb, johnbillion, noruzzaman, JeffPaul, joedolson, huzaifaalmesbah, amesplant, r1k0, shailu25.
Fixes #64762.

Committed in https://core.trac.wordpress.org/changeset/62025

[westonruter]

There seems to be a couple problems with r62025:

First, PHPStan is rightly identifying that $start_position could be false while $end_position is true. This is a problem since then it passes false into strpos() as well as doing $end_position - $start_position with a non-int value:

1476   Parameter #2 $start of function substr expects int, int<0, max>|false given.                              
       🪪  argument.type

This patch seems to be needed:

src/wp-includes/admin-bar.php

@@ -1472 +1472 @@
                         if ( is_string( $css ) && str_contains( $css, '#wpadminbar' ) ) {
                                 $start_position = strpos( $css, '#wpadminbar' );
                                 $end_position   = strpos( $css, '.wp-pointer' );
-                                if ( false !== $end_position && $end_position > $start_position ) {
+                                if ( false !== $start_position && false !== $end_position && $end_position > $start_position ) {
                                         $css = substr( $css, $start_position, $end_position - $start_position );
                                         if ( SCRIPT_DEBUG ) {
                                                 $css = str_replace( '/* Pointers */', '', $css );

Secondly, I get a test failure when I try to test just the group in isolation:

$ npm run test:php -- --group=64762

There was 1 failure:

1) Tests_Dependencies_wpStyleLoaderSrc::test_without_wp_admin_css_colors_global
Failed asserting that '' contains "/colors.css".

/var/www/tests/phpunit/tests/dependencies/wpStyleLoaderSrc.php:28

It appears the test was passing before since some not-cleaned-up global is making is_admin() return true, so it doesn't enter both branches of the conditional in Tests_Dependencies_wpStyleLoaderSrc::test_without_wp_admin_css_colors_global().

A data provider needs to be added to test both when is_admin() and when not in the admin.

There are a couple problems I identified with this commit. Details: https://core.trac.wordpress.org/ticket/64762#comment:24

[sabernhardt]

If strpos( $css, '#wpadminbar' ) is false, then str_contains( $css, '#wpadminbar' ) also should be false. Then $start_position would not be defined and no CSS would be added.

I had trouble with the unit test just to make it pass in the GitHub action, so someone else would need to edit that.

Trac ticket: https://core.trac.wordpress.org/ticket/64762

## Use of AI Tools

None 🧠

[westonruter]

Ah, yes. I see that. In that case, better to just do the strpos( $css, '#wpadminbar' ) check instead of str_contains( $css, '#wpadminbar' ).

I was working on that, but then I found a more significant issue with the implementation: it was doing an HTTP request to obtain the color scheme CSS for every frontend page load. This resulted in the logic not working in the default Docker development environment where loopback requests are unfortunately broken (at least for me anyway), but it also is a performance problem. Query Monitor warns about this with each page load.

I've taken a stab in ​this PR to refactor the logic to not rely on HTTP requests but to load the file from the filesystem instead. Additionally, I've split the single test into two, one for the frontend and the other for the backend.

I admit I'm not fully familiar with the existing assertions or what the logic in wp_admin_bar_add_color_scheme_to_front_end() is supposed to be doing. I tried adding assertions to test that the existing logic is working as expected. I'm not sure what this assertion was supposed to be checking for originally:

<?php
$this->assertFalse( wp_style_loader_src( '', 'colors' ) )

Or what this was asserting with r62025:

<?php
$this->assertStringContainsString( '/colors.css', wp_style_loader_src( '', 'colors' ) );

The tests may fail, however, in GHA due to the files not being built. So the test may need to write a sample colors.css for test purposes, similar to how we have to touch files in other unit tests.

@sabernhardt I'll invite you to my fork so you can push up additional commits.

With the Sunrise color scheme applied.

Before ❌

After ✅

[johnbillion]

Sorry but this implementation falls quite short of what I would expect it to.

• Why is a server-side HTTP request being performed on every front end page load to fetch the CSS file? Can the file not be loaded from the filesystem?
• Pulling out a substring from the stylesheet seems fragile.

I appreciate that we're trying to squeeze this into 7.0 but there are Sass files with the source colours for each colour scheme available in wp-admin/css/colors and a colors task in Gruntfile.js to generate the stylesheets.

Can the task be updated to generate a separate stylesheet that just overrides the necessary admin bar colours with those from each colour scheme?

This extracts the admin toolbar styles into a mixin so a standalone admin-bar.css file can be generated for each colour scheme. Facilitates custom colour schemes registering their own admin toolbar CSS file too.

Trac ticket: https://core.trac.wordpress.org/ticket/64762

## Use of AI Tools

Claude Code was used to initialise the separate admin bar color Sass files for each colour scheme. Worked ok-ish, I subsequently manually adjusted a lot of it.

[johnbillion]

I've taken a punt at this in ​https://github.com/WordPress/wordpress-develop/pull/11267.

I have tested this out with different color schemes on the frontend, and it works.

Thanks for putting together this PR @johnbillion! It looks fairly better than the current implementation.
I tested the PR on my side, and admin bar styles are correctly implemented on front end when we switch admin color schemes.

I was ​having trouble with the registered schemes for bbPress and Grey Admin Color Schemes because both plugins use wp_admin_css_color() within the admin_init hook.

• Switching the hook to init works for me on the front and back with Grey Admin Color Schemes and adding the fifth and sixth arguments. wp_admin_css_color( 'postmodern', __('Post Modern Grey', 'grey-admin-color-schemes'), plugins_url("postmodern/colors$rtl.css", __FILE__ ), array( '#464646', '#6D6D6D', '#D6D6D6', '#F1F1F1' ), array(), plugins_url("postmodern/admin-bar.css", __FILE__ ) );
• bbPress would need more editing, and I have not solved that on the front.

[mosescursor]

Test Report

Description

Frontend admin toolbar not using updated admin color scheme

This report validates whether the indicated patch works as expected.

Patch tested: REPLACE_WITH_PATCH_URL

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.5.4
• Server: nginx/1.29.5
• Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.5.4)
• Browser: Chrome 146.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

1. ✅ Issue resolved with patch.

Alternative option to ​https://github.com/WordPress/wordpress-develop/pull/11267 that uses the same Sass and built stylesheets but avoids using the $_wp_admin_css_colors global variable.

• Reverts the unit test to its original code.
• Does not enqueue a stylesheet for the Fresh color scheme.
• Enqueues an external stylesheet for the other 8 core schemes on the front end.
• Does not attempt to support plugins' color schemes on the front.

Trac 64762

## Use of AI Tools

@johnbillion shared these details:

Claude Code was used to initialise the separate admin bar color Sass files for each colour scheme. Worked ok-ish, I subsequently manually adjusted a lot of it.

[sabernhardt]

I was able to add Grey Admin Color Schemes on the front with PR 11267, but I would be more confident in that patch if someone could add color schemes from either bbPress or Jetpack on the front.

I submitted PR 11354 as an alternative option to consider, in case PR 11267 is not yet ready for this release.

[noruzzaman]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11354

Environment

• WordPress: 7.0-RC1-20260326.042417
• PHP: 7.4.33
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 146.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

1. ✅ Issue resolved with patch.

Video Link: ​https://vimeo.com/1177957494/aa513bbd90

[vgnavada]

Test Report

Description

I've tested using WordPress Playground (​https://playground.wordpress.net/wordpress.html?pr=11354) and can confirm the issue is resolved.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11354

Environment

• WordPress: 7.0-RC1-20260326.042417
• PHP: 8.3.30
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 146.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

1. ✅ Issue resolved with patch.

Supplemental Artifacts

Color Scheme LIGHT in wp-admin

Color Scheme LIGHT on Frontend

Color Scheme SUNRISE in wp-admin

Color Scheme SUNRISE on Frontend

Color Scheme ECTOPLASM in wp-admin

Color Scheme ECTOPLASM on Frontend

[gaisma22]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11354

Environment

• WordPress: 7.0-beta6-62085-src
• PHP: 8.3.30
• Server: nginx/1.29.7
• Database: MySQL 8.4.8
• Browser: Brave
• OS: Ubuntu 24.04
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None
• Plugins: None

Steps Taken

1. Went to Users > Profile and set color scheme to Sunrise.
2. Visited the frontend at localhost. Before patch: Admin toolbar showed default black colors despite Sunrise being selected.
3. Applied PR #11354 and hard refreshed the frontend. After patch: Admin toolbar correctly showed Sunrise colors.
4. Switched color scheme to Ectoplasm and hard refreshed. After patch: Admin toolbar correctly showed Ectoplasm colors.

✅ Patch is solving the problem

Expected Result

The frontend admin toolbar should match the admin color scheme
selected in the user profile.

Additional Notes

1. Bug confirmed on WordPress 7.0-beta6 - frontend toolbar displayed default black colors regardless of the selected admin color scheme.
2. After applying the patch, the toolbar correctly reflects the selected color scheme on the frontend across multiple schemes tested (Sunrise and Ectoplasm).

Screenshots/Screencast with results

Before Patch:

After Patch:

Thanks for working on this! I was perplexed why there was suddenly an extra HTTP request on very page by this function. 🤦

[wildworks]

#65080 was marked as a duplicate.

[pavanpatil1]

Patch Report
Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11354

Environment
WordPress: 7.0-RC1-20260326.042417
PHP: 7.4.33
Browser: Chrome
OS: Mac

Patch is working fine ✅

Expected result
The admin toolbar now matches the chosen admin color scheme.

Screenshot:

• ​https://www.awesomescreenshot.com/image/60076268?key=d9ca295d58cc93a3e57e414ad492c9ba
• ​https://www.awesomescreenshot.com/image/60076528?key=4c4d17f7e48524011f333b3d01181c51

[wildworks]

For the 7.0 release, it might be better to ship ​PR 11354, which has a minimal approach.

[jorbin]

Each of these proposed solutions is a fairly large, and we are only two days away from the new beta 1. I think reverting [62025] and punting this to 7.1 is the safest solution.

[desrosj]

Replying to jorbin:

Each of these proposed solutions is a fairly large, and we are only two days away from the new beta 1. I think reverting [62025] and punting this to 7.1 is the safest solution.

I tend to agree with this. Since this element has not matched the color scheme in the past, I think it's not surprising to a user if it does not after updating. Reverting gives us more time to find a better solution to this.

If we could find a minimal way to change the admin bar solely in the admin and leave it as it was in 6.9 on the front end for 7.0, I think that I would be in favor of that as an incremental step. But given that we're now less than 24 hours from the next pre-release, it's getting down to the wire.

Trac ticket: https://core.trac.wordpress.org/ticket/64762

## Use of AI Tools

[wildworks]

One drawback of reverting [62025] is that it causes a color theme mismatch between the frontend and backend. Specifically, the backend will use modern colors while the frontend will be stuck with the legacy fresh colors. This default color discrepancy did not occur in 6.9. As a more conservative approach, I've tried a PR that simply changes the frontend color theme to modern colors.

​https://github.com/WordPress/wordpress-develop/pull/11771

[sabernhardt]

I would prefer to revert [62025], even if the ticket stays in 7.0 (or moves to 7.1 and back to 7.0 if a patch is ready in time). Then the differences from 6.9 would be clearer.

PR that simply changes the frontend color theme to modern colors.

Anyone who purposely returns to the Fresh scheme should not have the Modern scheme CSS.

[wildworks]

PR that simply changes the frontend color theme to modern colors.

Anyone who purposely returns to the Fresh scheme should not have the Modern scheme CSS.

You're right. Indeed, it seems best to revert [62025] for now.

Closing this based on https://core.trac.wordpress.org/ticket/64762#comment:53

This reverts commit 421ac3612c1d221bcb930c29ac3a9252ed25d328 (r62025).

Trac ticket: https://core.trac.wordpress.org/ticket/64762

## Use of AI Tools

None

[wildworks]

In 62349:

Toolbar: Revert add CSS from admin color scheme on front-end.

The implementation issues a server-side HTTP request on every front-end page load and extracts the toolbar CSS via fragile substring matching. Alternatives are too large to land this late in the release cycle, so the fix is deferred to a future release.

Reverts [62025].

Props desrosj, jorbin, mukesh27, sabernhardt, wildworks.

See #64762.

[wildworks]

I propose backporting [62349] to the 7.0 branch.

[audrasjb]

Marking as dev-reviewed. Let's backport [62349] to branch 7.0.

[audrasjb]

In 62354:

Toolbar: Revert add CSS from admin color scheme on front-end.

The implementation issues a server-side HTTP request on every front-end page load and extracts the toolbar CSS via fragile substring matching. Alternatives are too large to land this late in the release cycle, so the fix is deferred to a future release.

Reverts [62025].

Reviewed by audrasjb, wildworks.
Merges [62349] to the 7.0 branch.
Props desrosj, jorbin, mukesh27, sabernhardt, wildworks.
See #64762.

[audrasjb]

I backported the [62349] revert to 7.0. Moving this ticket to 7.0.1 for further development.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[jorbin]

#65285 was marked as a duplicate.

[sabernhardt]

#65290 was marked as a duplicate.

[huzaifaalmesbah]

#65385 was marked as a duplicate.

This PR has already been committed. https://core.trac.wordpress.org/changeset/62349

Now that 7.0 has been released, I believe we can resume this PR towards 7.1.

[jorbin]

With ​PR #11267 looking like the best path forward and that PR adding new files which can't be done in a minor release, I am moving this to 7.1.

[huzaifaalmesbah]

Since ​Admin color scheme reflected in the Site Editor has landed for WordPress 7.1, I think this ticket would complement that work nicely. Having the frontend admin toolbar respect the selected admin color scheme would provide a more consistent experience across the Site Editor, wp-admin, and the frontend.

If everyone has the bandwidth to work on it, I'd love to see this land in 7.1 as well.

[softglaze]

Before patch, trunk 07220f23b7 (Sunrise scheme, front-end toolbar stays dark)

[softglaze]

Before patch, trunk 07220f23b7 (Ectoplasm scheme, front-end toolbar stays dark)

[softglaze]

After patch, PR 11267 (Sunrise scheme, front-end toolbar matches wp-admin)

[softglaze]

After patch, PR 11267 (Ectoplasm scheme, front-end toolbar matches wp-admin)

[softglaze]

After patch, PR 11267 (Fresh scheme, front-end toolbar)

[softglaze]

After patch, PR 11267 (Default scheme, front-end toolbar)

[softglaze]

After patch (page source showing admin-bar-color-scheme-css loading colors/sunrise/admin-bar.css)

[softglaze]

After patch (page source with Fresh scheme, no admin-bar-color-scheme-css present)

[softglaze]

Patch Testing Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11267

Tested the PR branch directly at commit 8a7542d6aa. This reflects the state of the branch from March, which is why the version string below reports as 7.0-beta5 and not current trunk.

Environment

• WordPress: 7.0-beta5-61991-src
• Subdirectory: No
• PHP: 8.3.32
• Server: nginx/1.31.3
• Database: mysqli (Server: 9.7.1 / Client: mysqlnd 8.3.32)
• Browser: Chrome 150.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.0

Steps taken

1. Cleaned trunk to commit 07220f23b7 and ran npm run build:dev.
2. Set profile color scheme to Sunrise and checked the frontend toolbar.
3. Set profile color scheme to Ectoplasm and checked the frontend toolbar.
4. Checked the page source on trunk to verify the current stylesheet behavior.
5. Fetched upstream pull/11267/head, checked it out, and rebuilt.
6. Set each of the four schemes, checking the frontend toolbar and page source for each.
7. ✅ Patch is solving the problem: The frontend toolbar now matches the selected admin scheme, and a per-scheme stylesheet is enqueued on the front end.

Expected result

• The frontend toolbar should visually match the color scheme chosen in the user profile.

Additional Notes

Scheme	Front-end toolbar	admin-bar-color-scheme-css	Stylesheet
Default	matches wp-admin	present	colors/modern/admin-bar.css
Fresh	matches wp-admin	absent	—
Sunrise	matches wp-admin	present	colors/sunrise/admin-bar.css
Ectoplasm	matches wp-admin	present	colors/ectoplasm/admin-bar.css

• Fresh scheme: no extra stylesheet is enqueued.
• Default scheme loads the stylesheet from the modern/ directory.
• The "Howdy, admin" submenu now properly follows the scheme; on trunk, it stayed dark.
• The PR branch is based on trunk from before [62349] and currently has conflicts. The last CI run was 16 March, meaning its logs and Playground artifact have expired.

Screenshots with results

Before:

• 64762-before-sunrise-frontend.png​
• 64762-before-ectoplasm-frontend.png​

After:

• 64762-after-sunrise-frontend.png​
• 64762-after-ectoplasm-frontend.png​
• 64762-after-fresh-frontend.png​
• 64762-after-default-frontend.png​
• 64762-after-sunrise-source.png​
• 64762-after-fresh-source-no-stylesheet.png​

I tested this branch locally at commit "8a7542d6aa". Default, Sunrise and Ectoplasm each enqueue their own admin-bar.css on the front end and the toolbar matches the selected admin scheme. Fresh enqueues no stylesheet. Note the branch can't currently be previewed via Playground (the CI artifact has expired).

@softglazee @fushar Appreciate your testing but I think #11354 supersedes this now. Are you able to take a look?

@johnbillion yes, i'm going to test #11354, and thank you

[softglaze]

Patch Testing Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11354

Environment

• WordPress: 7.0-RC1-62111-src
• Subdirectory: No
• PHP: 8.3.32
• Server: nginx/1.31.3
• Database: mysqli (Server: 9.7.1 / Client: mysqlnd 8.3.32)
• Browser: Chrome 150.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.0
• Gutenberg: not installed

Tested the PR branch at 794875760a (25 March), which is why the version string reads 7.0-RC1-62111-src. This is a different March snapshot from PR 11267.

Steps taken

1. Cleaned trunk to commit 5bc2c6228c and ran build.
2. Fetched pull/11354/head, checked out 794875760a, and rebuilt.
3. Confirmed both admin-bar.css (4329 bytes) and admin-bar.min.css (3926 bytes) are successfully generated by the Grunt task for each scheme.
4. Checked all nine options in the profile in the front-end page source.
5. Turned SCRIPT_DEBUG off, then rechecked the front-end source and Network tab for the minified path.
6. Installed the "Grey Admin Color Schemes" plugin, tested its three schemes, and re-tested a core scheme while the plugin was active.
7. ✅ Patch is solving the problem: Core schemes successfully enqueue their front-end styles (handling both minified and non-minified paths), and custom plugin schemes fall back safely without breaking.

Expected result

• The front-end toolbar should enqueue the correct stylesheet based on the selected core scheme and SCRIPT_DEBUG status.

Additional Notes

Scheme	admin-bar-color-scheme-css	Stylesheet
Modern (Default)	present	colors/modern/admin-bar.css
Light	present	colors/light/admin-bar.css
Blue	present	colors/blue/admin-bar.css
Coffee	present	colors/coffee/admin-bar.css
Ectoplasm	present	colors/ectoplasm/admin-bar.css
Midnight	present	colors/midnight/admin-bar.css
Ocean	present	colors/ocean/admin-bar.css
Sunrise	present	colors/sunrise/admin-bar.css
Fresh	absent	—

• With SCRIPT_DEBUG off, the source correctly requests admin-bar.min.css. The file returns a 200 OK and transfers 4.2 kB, confirming the production path works.
• For all three plugin-registered schemes (from Grey Admin Color Schemes), no stylesheet is enqueued on the front end. The toolbar gracefully falls back to the default dark style with no breakage.
• Core schemes continue to work (1/1 stylesheet enqueued) even while the color scheme plugin is active.
• The function returns early on is_admin(), meaning this logic is strictly front-end only. site-editor.php shows no stylesheet enqueued, which is the expected behavior.
• Note: fushar raised a color question on PR 11267, and it is worth noting that PR 11354 contains the exact same Sass commits (3700f88 and 8a7542d) from PR 11267.

Screenshots with results

• 11354-after-plugin-scheme-source-no-stylesheet.png​
• 11354-after-plugin-scheme-frontend-fallback.png​
• 11354-after-core-scheme-works-with-plugin-active.png​
• 11354-after-sunrise-source-scriptdebug-off-min-css.png​
• 11354-after-sunrise-min-css-loads-200.png​
• 11354-after-fresh-source-no-stylesheet.png​
• 11354-after-ectoplasm-frontend.png​

I have tested this branch locally at commit 794875760a. Here is the detailed breakdown of the behavior:

• Core Schemes: Modern, Light, Blue, Coffee, Ectoplasm, Midnight, Ocean, and Sunrise all correctly enqueue their respective colors/{scheme}/admin-bar.css on the front end. Fresh enqueues no stylesheet, as expected.
• Production Path (SCRIPT_DEBUG off): The Grunt task successfully builds both variants. When SCRIPT_DEBUG is false, the source correctly requests admin-bar.min.css, which returns a 200 OK (4.2 kB transferred).
• Plugin Schemes (Fallback Behavior): I tested this against the "Grey Admin Color Schemes" plugin. For plugin-registered schemes, no stylesheet is enqueued on the front end, and the toolbar safely falls back to the default dark style without any breakage. Core schemes remain unaffected and continue to work while the plugin is active.
• Site Editor: The function correctly returns early on is_admin(), so the stylesheet is not loaded in site-editor.php.

Full test report and screenshots have been posted on Trac #64762.

Just a heads-up that I have fully tested PR 11354 as requested. You can find the complete test report, including how it handles plugin-registered schemes and the minified production path, over on Trac #64762.

[ugyensupport]

@sabernhardt @audrasjb Which Patch should we foucs on to assure the case above

[sabernhardt]

Both pull requests have conflicts to resolve because the toolbar styles have changed since March, and #65445 might change the styles again this week. Two days is not enough for both tickets (and maybe not enough for either ticket).