![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 5 months ago
Last modified 4 weeks ago
#64762 reopened defect (bug)
Frontend admin toolbar not using updated admin color scheme
| Reported by: | huzaifaalmesbah | Owned by: | audrasjb |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Toolbar | Version: | |
| Severity: | normal | Keywords: | admin-reskin |
| Cc: | Focuses: | ui, css |
Description
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:
- Log in to WordPress.
- Visit the frontend of the site.
- 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.
Attachments (1)
Change History (71)
#4
follow-up:
↓ 13
@
4 months ago
- Keywords needs-patch added; 2nd-opinion removed
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.
#5
@
4 months ago
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.
#6
@
4 months ago
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.
#7
@
4 months ago
I agree with @johnbillion and @jeffpaul. Supporting the admin color scheme should apply to everything that's part of the admin, including the adminbar.
This ticket was mentioned in PR #11183 on WordPress/wordpress-develop by @huzaifaalmesbah.
4 months ago
#8
- Keywords has-patch added; needs-patch removed
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-baras 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
- Log in to WordPress.
- Go to Users → Profile and select different color schemes.
- Visit the frontend.
- Expected: The toolbar matches the selected color scheme.
@huzaifaalmesbah commented on PR #11183:
4 months ago
#9
#11
@
4 months ago
- Keywords has-dev-note added
@huzaifaalmesbah overall, this looks like a solid solution. I left some comments in your PR for you to review.
#13
in reply to: ↑ 4
@
4 months ago
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.
This ticket was mentioned in PR #11192 on WordPress/wordpress-develop by @sabernhardt.
4 months ago
#15
- Keywords has-unit-tests added
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_initaction (and possibly deprecated later if stylesheets are replaced with CSS custom properties, etc.). - Updates PHPUnit test.
Props: huzaifaalmesbah
Use of AI Tools: none (by me)
@sabernhardt commented on PR #11192:
4 months ago
#16
Built with code from #11183
@huzaifaalmesbah commented on PR #11192:
4 months ago
#17
Looks good to me, and we got the expected result.
https://github.com/user-attachments/assets/bfba1fb5-c5ba-47d8-ae9d-4bb8de7fda7e
#18
@
4 months ago
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
- Log in to the admin dashboard.
- Visit the frontend.
- Observe the color of the admin toolbar ( with different Admin color schemes).
- ✅ 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
#19
@
4 months ago
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
#20
@
4 months ago
- Keywords changes-requested removed
@SergeyBiryukov Please check how I edited the unit test.
#21
@
4 months ago
- Keywords commit added
Thanks for the PR @sabernhardt.
The unit test edits look good to me.
@audrasjb commented on PR #11192:
4 months ago
#23
Committed in https://core.trac.wordpress.org/changeset/62025
#24
@
4 months ago
- Keywords changes-requested added
- Resolution fixed
- Status closed → reopened
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
diff --git a/src/wp-includes/admin-bar.php b/src/wp-includes/admin-bar.php index b9c7872d0c..be623baf9f 100644
a b function wp_admin_bar_add_color_scheme_to_front_end() { 1472 1472 if ( is_string( $css ) && str_contains( $css, '#wpadminbar' ) ) { 1473 1473 $start_position = strpos( $css, '#wpadminbar' ); 1474 1474 $end_position = strpos( $css, '.wp-pointer' ); 1475 if ( false !== $ end_position && $end_position > $start_position ) {1475 if ( false !== $start_position && false !== $end_position && $end_position > $start_position ) { 1476 1476 $css = substr( $css, $start_position, $end_position - $start_position ); 1477 1477 if ( SCRIPT_DEBUG ) { 1478 1478 $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.
@westonruter commented on PR #11192:
4 months ago
#25
There are a couple problems I identified with this commit. Details: https://core.trac.wordpress.org/ticket/64762#comment:24
#26
@
4 months ago
- Keywords commit removed
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.
This ticket was mentioned in PR #11255 on WordPress/wordpress-develop by @westonruter.
4 months ago
#27
#28
@
4 months ago
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.
@westonruter commented on PR #11255:
4 months ago
#29
With the Sunrise color scheme applied.
Before ❌
After ✅
#30
@
4 months ago
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 ticket was mentioned in PR #11267 on WordPress/wordpress-develop by @johnbillion.
4 months ago
#31
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.
#32
@
4 months ago
I've taken a punt at this in https://github.com/WordPress/wordpress-develop/pull/11267.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
4 months ago
@andrewssanya commented on PR #11183:
4 months ago
#34
I have tested this out with different color schemes on the frontend, and it works.
@audrasjb commented on PR #11267:
4 months ago
#35
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.
@sabernhardt commented on PR #11267:
4 months ago
#36
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
initworks 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.
#37
@
4 months ago
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
- ✅ Issue resolved with patch.
This ticket was mentioned in PR #11354 on WordPress/wordpress-develop by @sabernhardt.
4 months ago
#38
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.
## 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.
#39
@
4 months ago
- Keywords changes-requested removed
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.
#40
@
4 months ago
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
- ✅ Issue resolved with patch.
Video Link: https://vimeo.com/1177957494/aa513bbd90
#41
@
4 months ago
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
- ✅ 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
This ticket was mentioned in Slack in #core-test by r1k0. View the logs.
3 months ago
#43
@
3 months ago
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
- Went to Users > Profile and set color scheme to Sunrise.
- Visited the frontend. Before patch: Toolbar showed default black colors.
- Applied PR #11354 and hard refreshed. After patch: Toolbar matched Sunrise colors.
- 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
- On 7.0-beta6 without the patch, the toolbar stays black on the frontend no matter what color scheme is set in the admin.
- Tested Sunrise and Ectoplasm. Both worked after the patch.
Screenshots/Screencast with results
Before Patch:
After Patch:
@swissspidy commented on PR #11255:
3 months ago
#44
Thanks for working on this! I was perplexed why there was suddenly an extra HTTP request on very page by this function. 🤦
#46
@
3 months ago
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:
#47
@
2 months ago
For the 7.0 release, it might be better to ship PR 11354, which has a minimal approach.
This ticket was mentioned in Slack in #core by jorbin. View the logs.
2 months ago
#49
follow-up:
↓ 50
@
2 months ago
- Keywords 2nd-opinion added
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.
#50
in reply to: ↑ 49
@
2 months ago
- Keywords 2nd-opinion removed
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.
This ticket was mentioned in PR #11771 on WordPress/wordpress-develop by @wildworks.
2 months ago
#51
Trac ticket: https://core.trac.wordpress.org/ticket/64762
## Use of AI Tools
#52
@
2 months ago
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.
#53
@
2 months ago
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.
#54
@
2 months ago
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.
@wildworks commented on PR #11771:
2 months ago
#55
Closing this based on https://core.trac.wordpress.org/ticket/64762#comment:53
This ticket was mentioned in PR #11783 on WordPress/wordpress-develop by @wildworks.
2 months ago
#56
This reverts commit 421ac3612c1d221bcb930c29ac3a9252ed25d328 (r62025).
Trac ticket: https://core.trac.wordpress.org/ticket/64762
## Use of AI Tools
None
#60
@
2 months ago
- Keywords dev-reviewed added; dev-feedback removed
Marking as dev-reviewed. Let's backport [62349] to branch 7.0.
#62
@
2 months ago
- Keywords has-screenshots has-patch has-unit-tests fixed-major dev-reviewed removed
- Milestone 7.0 → 7.0.1
I backported the [62349] revert to 7.0. Moving this ticket to 7.0.1 for further development.
#63
@
8 weeks ago
Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.
@wildworks commented on PR #11783:
6 weeks ago
#68
This PR has already been committed. https://core.trac.wordpress.org/changeset/62349
@wildworks commented on PR #11267:
6 weeks ago
#69
Now that 7.0 has been released, I believe we can resume this PR towards 7.1.
#70
@
4 weeks ago
- Milestone 7.0.1 → 7.1
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.
The front end intentionally did not use colors from the administration color scheme, and the
$_wp_admin_css_colorsvariable 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 theadmin-barstyle anddo_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.)