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. Before patch: Toolbar showed default black colors.
3. Applied PR #11354 and hard refreshed. After patch: Toolbar matched Sunrise colors.
4. Switched to Ectoplasm, saved, hard refreshed. After patch: Toolbar matched Ectoplasm colors.

✅ Patch is solving the problem

Expected Result

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

Additional Notes

1. On 7.0-beta6 without the patch, the toolbar stays black on the frontend no matter what color scheme is set in the admin.
2. Tested Sunrise and Ectoplasm. Both worked after the patch.

Screenshots/Screencast with results

Before Patch:

After Patch: