MP6: Custom color schemes don't apply to frontend admin bar.

[bpetty]

While the custom color schemes apply to the admin bar while in the administration backend, the admin bar reverts back to the default colors on any frontend pages while logged in.

[bpetty]

I've made an attempt to fix this myself, but can't seem to wrap my head around how these custom color scheme styles should be enqueued in the frontend for the admin bar, so I'm leaving this to someone more qualified.

[helen]

This was on purpose - color clashing, not loading color schemes on the front, etc.

[nacin]

#26711 was marked as a duplicate.

[johnbillion]

We should re-visit this. It's jarring when you visit the front end of your site and the admin toolbar colour scheme changes.

Relevant plugin: ​https://wordpress.org/plugins/admin-bar-color/

[knutsp]

-1
I would not want the front toolbar colors to default to the admin toolbar colors.
Plugin material.

[johnbillion]

Replying to knutsp:

I would not want the front toolbar colors to default to the admin toolbar colors.

Why not?

[knutsp]

The admin toolbar relates to the complete admin color scheme. The front toolbar has to relate to the theme and be visually different. One should not confuse the toolbar with the theme design. The default is dark, and that goes well with most themes. There is no risk of color clash.

Today you may select the admin color scheme completely independent of the site theme, and choose form predefined schemes available. It may come with a deep blue admin toolbar. On the front there may be another kind of blue, and those blue variants may not look good together. So I would have to design my own admin theme with a toolbar that matches the site theme, which may not look good with the rest of the admin theme, and so on. It's a mixup.

In short: The aesthetics will suffer. So please leave this to a plugin.

[DrewAPicture]

I'm also -1 on matching the front-end styles for all of the reasons outlined in previous comments. Suggest wontfix.

[morganestes]

Based on the comments and the fact that there's a plugin available to accomplish this, I'm going to close this for now.

[netweb]

Sitting on the fence here, I see pros and cons on both sides of this ¯\_(ツ)_/¯

Though, as it's now been closed I'm pulling the milestone :)

[ocean90]

#38687 was marked as a duplicate.

[zodiac1978]

Some people (like me) are using the color schemes to remind me that I'm using the dev or staging system. For this case it would be helpful to have the color scheme used on the frontend.

(Just to add a real use case reason for changing this behavior.)

[SergeyBiryukov]

#40312 was marked as a duplicate.

[sagarprajapati]

Right point @zodiac1978

I have always use the color schemes to remind the dev or staging system. I have attached patch for the solution of above issue. Please check it.

Thanks

[msaggiorato]

I think we should revisit this.

I'm also one of the people using color schemes to identify different environments, and having the frontend admin bar not respect the set admin_color setting, is confusing (even not in this use case, for consistency reasons).

Not sure if the patch works nicely with the current version of WP, but we should at least reopen the conversation about this.

Thanks

[zodiac1978]

If someone looks for a solution, there is this plugin:
​https://wordpress.org/plugins/contextual-adminbar-color/

From the description:

Since WordPress Core will probably deprecate alternate admin color schemes in mid-term, this plugin is meant to be use by those who rely on colors to know is they are in staging, preproduction or production environment.

[desrosj]

While there are valid use cases here and fixing this does not appear to require a large amount of code, nothing I've presented here, in my opinion, has been enough to overrule the original design decision.

Another way to indicate the environment type for a site would be to add an individual node in the admin bar with a specific color, similar to how Query Monitor shows an admin bar item that is red if there are PHP errors reported.

I think the use cases also fall well outside of the ​80/20 rule.

Because there are two plugins that solve this issue (both of which still work), I'm going to close this out again.

One note: the version field is used for specifying the first version of WordPress that is affected by the issue reporting. Since MP6 was merged in 3.8, changing that back.

[johnbillion]

#51674 was marked as a duplicate.

[dlh]

#53862 was marked as a duplicate.