The ending comma with no following selectors could very well be causing trouble.
I just looked a bit for an online scss linter but but all I saw were dev side. Short of using a linter, that leaves manually pairing up curly braces - ugh!
In this stylesheet in particular the commas are at the end of many lines because itās a work in progress and I add elements piece by piece. BTW the commas do not produce any errors infact I see the changes when I click Save.
Comments in my stylesheet now are both // or /* */ . I see that some online SCSS validators dislike //. But not Discourse.
As I said itās a work in progress, I really donāt like use // but I wanna try the new panel with SCSS and for now thereās no problem in the preview.
When I finish the work (itās mostly a rework where Iām cleaning the old stylesheets that I wrote over the years) I want to use only /* */ for comments.
It doesnāt seem like colors donāt seem to update when a theme updates a color scheme.
I updated a color scheme in my theme repository. It updates the color scheme in the admin ācolorsā page correctly, but does not update the resulting css.
Correct theme selected:
Selected colors correctly changed on theme update:
Resulting icons should be blue, nothing in the theme overrides. I have a separate color scheme with the exact same colors that works with this:
Edit:
A rebuild fixed the colors, but this seems strange as to why Iād need to rebuild the entire site just to apply the correct color theme.
1 Like
Hi Jeff,
I can not reproduce this issue at all, can anyone else? What are the exact steps?
I canāt reproduce it now, but when I was creating the material design theme I experienced similar issues. I didnāt have to do a rebuild, but I did have to re-save the CSS after changing the colors for the variables to reinitialize. As I said, can no longer reproduce that behavior so that might have already been addressed.
2 Likes
I think these are the full steps I did - Iāll try and reproduce today to confirm.
Create a theme repository with no color theme attached.
Import the theme into a discourse instance.
Apply the theme as default, attach an existing color theme.
Push an update to the theme to have a color scheme.
Pull the changes and switch to using the new (theme owned) color theme.
Push an update to the themeās colors (no CSS changes)
Pull changes into discourse. Noticed that no colors change.
I didnāt try to edit the CSS in the theme, since I figured it would do it on the theme pull.
I can recreate this behavior on my local dev environment, but not on the Digital Ocean docker instance. On local, as soon as I make a change to the CSS and save it, it refreshes with the correct colors. If it happens on my docker instance I will let you know.
EDIT: I have recreated in production as well, but the same as above, as soon as I re-save the CSS file, the colors return to normal.
Ahh so this is specifically for an updated color scheme from a remote repo? I will add a test for it.
I am not using a color scheme from a remote repo. These are my steps to reproduce:
- Create a theme that uses a color variable. Something as simple as:
.d-header{
background-color: $header-background;
}
- Save your changes and apply theme with some custom color scheme
- Change color of header background in Customize > Colors
Observed Result: The background color of the header doesnāt change unless you go back in to your theme and re-save the CSS
4 Likes
Yeahā¦ that makes sense, I forgot to invalidate theme on color var changes, I only invalidate the app.css, will fix.
8 Likes
4 Likes
Thanks for the quick fixes Sam, I can confirm on my side that the colors change immediately ā looks great!
Edit: Not sure if this is a bug here, or in the materials design theme, but it does not seem to update for some components - various elements that use lighten() functions are not pulling from the newly specified color schemes for some reason? Hereās a screenshot when swapping the material design theme from the Material Dark color theme to the Blue/Red theme. The topic body doesnāt look like itās updating its colors correctly ā
(sorry for the cruddy screenshot; ubuntu wants to not play nicely with screenshot tools right now)
specifically this element:
https://github.com/discourse/material-design-stock-theme/blob/b103aeb00dda3602ad87b13c0544dc8c17e75d3e/desktop/desktop.scss#L53
is being computed as:
.category-list, .topic-list:not(.categories) {
...
background-color: #3b3b3b;
...
(Where secondary is fafafa for the chosen color theme.)
If it helps, this is not the default theme, but a user selectable one. The default themeās secondary is 202020
Can you touch CSS is the theme (which should fix it) and then see if you can break it again?
Be sure to check out latest in āTheme Landā cause you can now ship custom fonts if you need toā¦ 
1 Like
I can confirm that touching the CSS fixes this, but changing the color theme breaks it again back to #3b3b3b
(Running v1.8.0.beta11 +140 in case I didnāt grab the latest patch somehow.)
You are going to need to be on +147 I think. Try getting latest.
1 Like
If a font is freely available via a CDN (like Google Fonts) is there any reason to ship them like this vs a link?
It will work behind firewall I guess, but same pattern works for any asset
1 Like
Must have tried to rebuild+pull too soon ā looks like this in good, working order post updates - thanks Sam!
Edit: Should a user selected theme be attached to a specific client/browser, or for the specific user login? I seem to have the ability to pick different themes across different browsers for a single user ā is this the expected behavior?
3 Likes
Yes that is the expected behavior, user themes are āper deviceā and a different browser is a different ādeviceā.
3 Likes