The changed color module never simply loads the styles from your theme directory. It always uses those it creates in /files/color. It also creates a folder there for your default Color Scheme.
This makes it very hard - if you are recoloring images, even imposssible - to work on a theme with color module switched on and is surely not intended.
I use Alpha 3 and applied the patches by Ksenzee and sun, so have not checked with a brandnew dev checkout of D7.


For any image you have recolored by color module you just cannot use your default image from the styles folder, it always uses a recolored version (which is correct for any other than the default color scheme).
Formerly if you chose the default Color scheme, Color Module was practically inactive and just used the styles you have in your theme directory. I would very much opt for restoring this.
The new behaviour must come from the latest patches to Color module:
http://drupal.org/node/693504#comment-2801502
http://drupal.org/node/693504#comment-2819954
I did not unapply all patches to find out which one is causing it, so I am not sure who is the culprit here, or is it even intended?
It may have to do with me using Alpha 3 but using these patches, but I do not really believe that.
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot-014.png | 13.02 KB | eigentor | |
| Screenshot-013.png | 9.04 KB | eigentor |
Comments
Comment #1
eigentor commentedAs a workaround for the moment: When one switches color schemes, it takes in new CSS rules from the theme directory, so it is at least possible to load those.
Comment #3
EvanDonovan commentedSubscribing. Hopefully I'll get a chance to look at this soon (in terms of testing, not necessarily coding a fix...)
Comment #4
dcrocks commentedI am using drupal 7.x dated 4/3. When I select the default color scheme in garland or bartik the system uses theme items in the theme directory and does not create a copy of the default theme in files/color. It even deletes the directory of modified files previously created for that theme in default/files/color.
I tested and it also rebuilds the files in files/color each time you do a save configuration from the settings page even if you haven't made any changes. So you could work on items in your theme directory and implement them simply by doing a save configuration in appearance/settings.
Comment #5
EvanDonovan commentedPossibly I'm wrong, but isn't this by design? The color.module has to use custom css files since the colors are dynamic.
Comment #6
eigentor commentedEvan Donovan: No, the default setting always used to use the theme directory directly.
Am going to cross-check with garland, Bartik and Corolla if this is due to some erroneous code in my color.inc.
Comment #7
EvanDonovan commentedOh, I see. The default setting would use the theme directory directly, and the custom settings would not, if I'm understanding you correctly.
In ksenzee's initial roll of the patch, the "default" setting still said "custom." In the one that was committed, that had been fixed, but perhaps it was still custom in the sense of where the color module would pull CSS from.
Comment #8
eigentor commentedAh, like I suspected: My error is due to some bug in my color.inc.
I tried Corolla and it uses the theme directory for the default style without a problem.
Let's leave this open nonetheless, until I found out what is the cause for the error, because other theme creators might step into the same trap.
Comment #9
EvanDonovan commentedYeah, sounds like a documentation issue perhaps.
Comment #10
Steven Merrill commentedI agree that this isn't an active bug - using D7 CVS HEAD as of a few seconds ago and the color.inc from Bartik currently in #762474: Get Color Module Preview to work, going back to the default scheme stops the colored CSS files from being loaded from the files directory.
Comment #11
tim.plunkett