As of yesterday’s update (of my hosted server at https://doomemacs.discourse.group), none of my custom CSS is applied. Changes to my theme(s) or components’ CSS have no effect (though changes their <head> or other HTML sections work fine).
There is one suspect link tag pointing to an empty stylesheet, whose hash changes each time I change my CSS. It appears Discourse is silently failing to compile my stylesheets. There are no mentions of failures in my error logs and discourse_theme uploads my stylesheets without complaint, but to no effect.
Thank you! The stylesheets now correctly load, however, the SCSS color variables don’t appear to inherit my theme’s color scheme. e.g. $secondary yields its default value, #ffffff, instead of #282c34. Is this perhaps another regression from e8b8272?
Yes, it is another regression. It’s a bit of a tricky fix… and for the vast majority of color variables, theme components should be using CSS custom properties. You can look at this guide Updating themes and plugins to support automatic dark mode, for an overview and some examples on how to add custom color variations in a special color_definitions.scss file in your theme component.
Yes, that makes sense, did you try adding that SCSS above to a new file in common/color_definitions.scss? It should just work if you add it there. (There is also a tab in the UI for that special stylesheet.)
It’s certainly possible, only inconvenient, because it’ll require hundreds of lines of boilerplate scss per-theme (and a build system for it to share variables across them all) that weren’t necessary a week ago. That said, it’d probably be best to do this anyway, to avoid issues with future refactors of Discourse’s build process. I’ll do that. Thanks!
That guide is a bit outdated, yes, although what is tripping up in your case is not core variables but rather SCSS colors in a component not inheriting the theme’s color scheme. (Nonetheless, I will go through the guide and update it.)
A little bit of context: in August/September 2020 we moved to using CSS custom properties for colors. The main reason for that change was so that we could support automatic dark mode in a way that was light and fast. Themes have CSS and JS, so they cannot be switched quickly, but using CSS custom properties, color schemes can be flipped on the fly, without refreshing the page.
I see in your site that you have 4 themes with a color scheme each and a component shared across the themes for the shared styles. You could achieve essentially the same thing with one main theme (that would contain all the shared styles) and 4 user-selectable color schemes. You would need to move all color calculations in the color_definitions.scss file of the main theme, but it is doable, I’ll try to find some time and give this a shot tomorrow.
That would be ideal, but I arrived at the current setup because multiple color schemes wouldn’t work for me. Some color schemes produce poor colors for auto-generated variables like --primary-low. Simply redefining the variable may work for one color scheme, but not another. A more general solution is possible if we redefine it based off $primary, or conditionally based on color scheme id/name, but without either multiple themes is necessary, so I can have a per-theme color_definitions.scss (the duplication I’d like to avoid). Or is there a better option I’m missing?