Open CindyPoole opened 10 months ago
Thanks for your report, and welcome to Backdrop on Github!
I hadn't come across the issue before, but was able to reproduce it, experimenting with the Color settings of the theme. Have you maybe changed some Color settings before you encountered the issue?
When I changed the "Footer Border" color in the Thesis theme settings (admin/appearance/settings/thesis
) to black, I noticed the behavior you describe. Some elements (not only the footer border) became black, and in the browser dev tool I get the notion that the color values in skin-thesis.css
were changed to #000000
. That's however not the case, the CSS file is the same as before.
So far, I don't have an explanation for this odd behavior. I even wasn't able to reverse the unwanted color change by resetting the theme colors. In this situation, the only way to make the actual colors from skin-thesis.css
visible again, was to disable the Color module. (Would this work for you as a temporary workaround?)
There is a Backdrop core issue regarding color settings of sub-themes. Not sure, but it might be related: https://github.com/backdrop/backdrop-issues/issues/4463
I've been able to reproduce following these steps:
color.module
is enabledskin-thesis.css
as suggested by the OPVisit the front page - everything is fine, the css classes in skin-thesis.css
are applied correctly.
admin/appearance/settings/thesis
and choose a different preset color setadmin/appearance/settings/thesis
again, and choose back to Basis (default) color set. Clear cachesSo, at this point, there doesn't seem to be a way to change that back to the definition in skin-thesis.css
. The only way is to disable color.module
.
So, if you can, disable that module, and then the theme will use the colors correctly.
As a sidenote: the Color module actively rewrites the cached css files for the site. Those files are stored in files/color/thesis-XXXX
. Every time the caches are cleared a new version of those css files is created, and stored in a new folder. skin-thesis.css
is among the rewritten files, since it's found in the css folder of the theme. Although the color for l-footer
is not supposed to be rewritten, what happens is that the color for that class is run through _color_shift()
, which results in it being modified to #000000. I'm not sure if this is intentional, or if it's a bug.
I have found another workaround that allows to keep Color enabled (in case you are using for other elements), BUT it also respects the overrides you made in thesis-skin.css
.
core/themes/basis
color
with its content (it contains color.inc
)themes/thesis
. So the folder color and its content should be found at themes/thesis/color
@olafgrabienski: this is a simple change to the theme that will assure other people won't run into this problem.
So, I think this is what's happening.
color.inc
in the Thesis theme folder. Color needs this file to build a configuration file called thesis.settings.json
which contains a list of the css files to be rewrittenthesis.settings.json
from scratch AND adds ALL css files it can find in the Thesis theme's css folder, including skin-thesis.css
!skin-thesis.css
is added to that config file, meaning that Color will REWRITE all colors in skin-thesis.css
By adding Basis' color.inc
to the theme Thesis theme, we are telling Color to ONLY use the files listed in that file when creating thesis.settings.json
. This means that skin-thesis.css
will never be included in that list, and therefore those colors will never be rewritten.
@argiepiano Many thanks for confirming the issue and for your instructive findings. I'll test the workaround as soon as possible.
- In your installation folder, head to
core/themes/thesis
Probably just a typo, I guess it should be core/themes/basis
.
Probably just a typo, I guess it should be core/themes/basis.
Yes! I'll fix
@argiepiano Thank you so much! I have placed a copy of the color folder into the thesis folder, and everything is working as it should now. Your help is very much appreciated.
I have changed some colors in skin-thesis.css as follows:
But after clearing the cache, each time in the browser window they appear black. Using Firefox Dev console, it's showing the css code has actually been changed to #000000. But in the actual file, it remains the original colors as defined above.
Has anyone come across this before? It's not just Firefox, when I preview the site in Safari the areas are showing black there too, so it appears to be changing all my colors to black when processing the css file.