Color palettes loading incorrectly with 2.7.0.beta5

Contribute Bug

AI-generated summary

Issue Summary: Color Palettes Loading Incorrectly with 2.7.0.beta5

After updating to 2.7.0.beta5, users smrtey and gkln reported that their color palettes were not loading correctly. The default “Light” palette was being used instead of the assigned palette. This issue occurred when using theme components, but not with the base theme.

Troubleshooting and Workarounds

  • smrtey found a temporary workaround by manually adding the desired sass color variables to each theme and component.
  • awesomerobot suggested disabling components one by one to identify any silent errors.
  • smrtey discovered that the issue occurs with any component using scss color variables.

Bug Fix

  • The bug was identified and fixed by pmusaraj.
  • Updating to the latest version should resolve the issue.
  • It is recommended to update theme components to use CSS custom properties instead of SCSS variables, which will enable automatic dark mode and make color overrides easier.
1

Updated to 2.7.0.beta5 this morning and lots of colors had changed. Looks like the Color Palette isn’t being read correctly and the default color palette that you get when you click on New Palette is being used instead. The two themes below use two different color Palettes, but both end up with the Discourse “New Color Palette” → Base palette: Light defined in the first line of the CSS

Example 1:
This is the theme’s Color Palette:

image
image688×649 24.9 KB

Here is the first line of the css

$primary: #222222 !default; $secondary: #ffffff !default; $tertiary: #0088cc !default; $quaternary: #e45735 !default; $header_background: #ffffff !default; $header_primary: #333333 !default; $highlight: #ffff4d !default; $danger: #e45735 !default; $success: #009900 !default; $love: #fa6c8d !default;

Example 2:
This is the theme’s Color Palette:

image
image384×512 85.6 KB

Here is the first line of css

$primary: #222222 !default; $secondary: #ffffff !default; $tertiary: #0088cc !default; $quaternary: #e45735 !default; $header_background: #ffffff !default; $header_primary: #333333 !default; $highlight: #ffff4d !default; $danger: #e45735 !default; $success: #009900 !default; $love: #fa6c8d !default;

If I start with a blank new theme and add a palette, it works as expected, but for my existing themes, the Default Light Palette gets loaded instead of the Palette that is assigned.

1 Like
2

So far the only way I can find around this is to manually add the sass color variables I want to each theme and component.

1 Like
4

I’m unable to reproduce this issue… if you change the color palette on an existing theme, does it remain incorrect?

3 Likes
5

It seems we have the same issue. Updated to 2.7.0.beta5 (6c57f6f49d) and the color scheme was no longer applied in our theme component.

We use:

#meta-links {
    background-color: $header_background;
}

but the background color was #fff instead of the color defined in the color scheme.

I tried:

  • re-assigning the color scheme to the theme
  • copying the color scheme and assigning the copy to the theme
  • re-assigning the theme component to the theme

but it did not seem to work. The current workaround is to manually set the color in the CSS.

2 Likes
6

It seems like what’s happening is that it loads the correct palette for the base theme, but not for any of the components. So the parts of the page that don’t use a component have the correct colors, but the parts that rely on a component load the default Discourse “Light” palette instead of using the palette that’s assigned to the Theme.

From Developer Tools
color_definitions.scss has the correct palette

image
image973×118 12.9 KB

desktop.scss has the correct palette
image

theme_174.scss which is a component, uses the default Light palette
image

theme_171 is a component that consists of only these lines of css in common.css and nothing else

#banner {
    margin: auto 20px;
    background-color: $primary-low;
    max-width: 880px;
    border: 1px solid #999 ;
}
2 Likes
7

Thanks @gkln and @smrtey for the additional details… one thing to try is to disable components one by one to see if that changes anything… It’s possible there’s a silent error that’s not being called out somewhere, and that may be breaking CSS for components.

8

It seems to happen with any component that uses scss color variables. Everything works fine if I manually add the colors to every individual component:

$primary: #22262a !important; $secondary: #fefefe !important; $tertiary: #2572e4 !important; $quaternary: #518ee9 !important; $header_background: #1550a7 !important; $header_primary: #fcfcfc !important; $highlight: #9edaf5 !important; $danger: #ff7114 !important; $success: #85cc54 !important; $love: #de0100 !important;

but that is far from an ideal solution. I don’t see how I can troubleshoot this. There is absolutely no way I have the capacity to figure out what could make Discourse load a different color palette.

1 Like
12

ok, @pmusaraj took a closer look and found the bug… it has been fixed here:

…so updating your sites again should fix it.

If these are theme components you’ve built, we recommend updating them to use CSS custom properties instead of our SCSS variables. The switch means you can use automatic dark mode, and makes color overrides easier. More details here:

6 Likes