Basis subtheme, with one custom.css file (in subfolder /css of the subtheme). Custom.css contains more than one color declaration; one for background-color is what raises this issue. The declaration is used to set the background color of blocks contained in each of two sidebars.
With Color module disabled, the background-color declaration (for the given class) in custom.css works as intended / expected. I get the background color I code for in the place where I want it. But my customizations through that module for other parts of the theme of course disappear.
With Color module enabled, it highjacks all of the active css files (from parent theme and subtheme, including custom.css) and writes them to /files/color/[subtheme name with generated hash characters]. Which is OK, except that it then goes farther and replaces all of the color codes (#A2B3C4) in custom.css with zeros (ie, black, #000000). I've found that it won't overwrite an added transparency marker (#00000010, for example -- which shows as light grey). (If it is taking that value from one of the color values in the theme settings page, it isn't clear which one. And even if it were, I'd probably want to keep the chosen color. Just don't overwrite my custom.css.)
I looked into color.module, and I see places where it manipulates css files. I'm don't read PHP to see more than that.
In Firefox inspector, I can edit the indicated color value, and the browser will then display it correctly.
Deleting the custom.css file from the generated /color subfolder only causes the program to re-generate a new /color subfolder, with the re-written custom.css file.
I don't see a configuration setting that says "don't edit custom.css".
Thanks for any insights.
Comments
Hi DonM, I guess there isn't an option for the color module to behave in another way, but there are workarounds:
Hi, Olafski,
Thanks for your reply. Thank goodness we have the resources of Drupal 7 to look at when these questions arise -- questions new to me (yet another unknown part of Drupal / Backdrop CMS), but not to the broader community.
I found the answer in some old posts about the Color Module for Drupal. I had seen a hint in the Basis skin.css file itself (near the bottom) -- but didn't understand it. The hint wording is ambiguous -- I took the wording to be a warning to users like myself not to touch that particular section. Turns out the intended meaning is how Color Module implements the functionality I wondered about at the end of my question.
So the simple answer is to include the "don't touch" comment in my own custom.css file, near the top. Everything below it is safe from the Color Module re-write function.
/* Color Module: Don't touch */
Problem solved. On to the next challenge...