PR #78397 made the Site Editor's sidebar and page shell follow the user's WordPress admin color scheme instead of always rendering a fixed dark background. This is a great improvement, but it currently only works for the built-in admin color schemes.
Custom color schemes registered by plugins via wp_admin_css_color() are not picked up, since the colors are now sourced through getAdminThemeColorsrather than from PHP's full list of registered admin color schemes.
This breaks the experience for plugins that let users define and apply custom admin color schemes across wp-admin (like mine, Admin Color Schemes). Before #78397, it didn't matter, as the color schemes did not apply & were not visible; now that the admin bar is visible in the Site Editor and the core schemes apply, users of custom schemes get a visibly mismatched/inconsistent experience.
Current behavior
getAdminThemeColors in packages/admin-ui/src/admin-theme-colors maps a fixed, known set of admin color scheme slugs to primary/bg values used by ThemeProvider.- Any scheme slug outside that known set (i.e. any custom scheme registered via
wp_admin_css_color()) isn't represented, so the Site Editor falls back to a default rather than the plugin's colors.
Proposed solution
Add a JS filter hook that lets plugins supply their custom scheme's colors to the Site Editor's theme color resolution. This could run in getAdminThemeColors to extend the list of ADMIN_THEME_COLORS.
Additional context
I have a PR in progress implementing this filter idea, and a branch to my admin color schemes plugin to demo using it — I'll post those shortly, but I'm opening this issue for any feedback on the filter idea.
Environment
- WordPress version: 7.1 beta or 7.0 + GB
- Gutenberg version: 23.6
PR #78397 made the Site Editor's sidebar and page shell follow the user's WordPress admin color scheme instead of always rendering a fixed dark background. This is a great improvement, but it currently only works for the built-in admin color schemes.
Custom color schemes registered by plugins via
wp_admin_css_color()are not picked up, since the colors are now sourced throughgetAdminThemeColorsrather than from PHP's full list of registered admin color schemes.This breaks the experience for plugins that let users define and apply custom admin color schemes across wp-admin (like mine, Admin Color Schemes). Before #78397, it didn't matter, as the color schemes did not apply & were not visible; now that the admin bar is visible in the Site Editor and the core schemes apply, users of custom schemes get a visibly mismatched/inconsistent experience.
Current behavior
getAdminThemeColorsinpackages/admin-ui/src/admin-theme-colorsmaps a fixed, known set of admin color scheme slugs toprimary/bgvalues used byThemeProvider.wp_admin_css_color()) isn't represented, so the Site Editor falls back to a default rather than the plugin's colors.Proposed solution
Add a JS filter hook that lets plugins supply their custom scheme's colors to the Site Editor's theme color resolution. This could run in
getAdminThemeColorsto extend the list ofADMIN_THEME_COLORS.Additional context
I have a PR in progress implementing this filter idea, and a branch to my admin color schemes plugin to demo using it — I'll post those shortly, but I'm opening this issue for any feedback on the filter idea.
Environment