A Colorized Theme stores its active CSS in a special directory: “%bsites/default/files/color/theme_name-random_8_hexadecimal_digits_value”
(forced to all lowercase)
Example: “/sites/default/files/color/garland-1a2b3c4d”
The .css files stored in the main Theme directory (%t) are only used as templates by the Color module for generating the colorized version in the above directory which are the ones actually sent to browsers.
For that matter, should the “%t” variable itself be switched to the “/sites/default/files/color/…” directory instead of the standard Theme directory in case of a Colorized Theme?
Perhaps more variables could be made?
%t = base directory of current Theme (as it is now, for backwards compatibility)
%p = directory of current Theme’s parent Theme (e.g. Garland in case of Minnelli) as per an older Issue (if no Parent, then %p = %t)
%a = actual active Theme directory — the directory where the final .CSS actually comes from, including from a Colorized Theme (if non-Colorized, then %a = %p)
“Use Theme CSS” would use the .css file(s) found in %a.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | wysiwyg.color_.492618.patch | 1001 bytes | adamps |
Comments
Comment #1
sunIf you use Color module, then you should not use a custom CSS file definition at all.
Marking as duplicate of #436030: Modify theme CSS by user-defined styles. You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.
However, thanks for taking the time to report this issue.
Comment #2
Joel MMCC commentedThanks for the quick response! I wish other project maintainers were as diligent!
I read that Issue #436040 (including all comments) before submitting mine. It is not a duplicate, and has nothing to do with the Color module.
When I use “Use Theme CSS,” then the Editor (TinyMCE in this case) content and its own Preview (not Drupal’s Node Preview, of course) looks like generic default HTML for the most part: Verdana font, black regular text, blue hyperlinks, etc. This is nowhere near what my Theme displays (because I customized the generated CSS, not the template).
When I use “Define CSS” and manually place the path to the “sites/default/files/color/…/style.css” in it, it seems to work okay for the most part. The Editor shows the proper fonts and mostly the proper colors (which I customized directly in the color-generated style.css instead of the template one), and TinyMCE’s Preview looks quite close to what would actually display.
But, of course, if I tried to alter the colors (which I wouldn’t for this particular site, as I have them set to match the client’s logo), it would generate a new folder with new graphics and new style.css, and I’d have to copy my customizations from my backup of the previous folder. I’d also have to remember to go into WYSIWYG and change the path there as well.
The idea of this issue is to prevent having to do that last step by simply having “Use Theme CSS” work as its name implies and use whatever CSS file(s) are actually served by the current Theme, regardless of the nature of the Theme (Child Themes, Colorized Themes, Colorized Child Themes, Zen Themes, other theme-engine Themes, etc. etc. etc.).
Yes, that other issue, namely, having a “Use Theme + Custom CSS” option, would be nice, but this is still a separate issue entirely. “Use Theme CSS” should mean “Use Theme CSS” — what an average Drupal site builder would understand that to mean, namely, using the CSS of the currently active Theme regardless of its nature.
Comment #3
adamps commentedThe problem still seems to be present - in essence, "Use Theme CSS" doesn't take account of the core Color module.
In #2289683: Get all stylesheets from a theme, TwoD is working towards a general solution for this and other CSS that doesn't get picked up. At the time of writing the patch is awaiting review and testing.
I put together a patch for my own purposes applying to this specific problem only. I'm definitely not an expert in this area, but it works for me and I hope it might help someone. Arguably it's not the ideal approach as it relies on reading the variables of the color module, and so might stop working if anything changed there. However in practice, hopefully core is fairly stable.
Comment #4
twodAs @AdamPS said, the other patch takes a more general approach and conflicts with this one.
I've also just updated it with the ability to select which theme to get stylesheets from, and if that one is colorized it should work just fine.
I'm not sure I'll be able to backport that patch to D6 though...