choosing "Aggregate and compress CSS files" disrupts styling

I think this is a symptom of this bug #2056331: Styling for messages, form items, "more" links, and pagers missing from upgraded sub-themes

Please try the work-around described in that issue. If it doesn't fix your problem, please re-open this issue. Thanks!

The fix is now in 7.x-5.x-dev and a new 7.x-5.4 release is forthcoming.

I am using the most recent version of the Zen responsive. I created a child theme and have customized that. I get the same error as others in this thread regarding problems when aggregating CSS. After my basic testing I found that 2 css files were not being included despite being called in the "styles" css. One was a custom css of my own for columns within content and the other was "misc.css" (../mytheme/components/misc.css).

To resolve my problem I removed the calls from the "styles" css and added them in the "mytheme.info" file (/mytheme/mytheme.info) below the lines beginning "Then we add our own stylesheet." Here, I added "stylesheets[all][] = css/components/misc.css" and another line with my custom columns css too. At this point, things seem to work OK. I haven't done extensive browser testing but I'm feeling pretty good about it's being OK.

I only hope there aren't similar issues with the JS Aggregate feature since those could be far less obvious to reveal themselves. ... fingers are crossed I guess.

I am seeing the same issue. When we turn on "Aggregate and compress CSS files." option, it appears as though the "@import "components/misc.css";" line in the styles.css file does not get processed.

I have tried the patch from bug #2056331 but I think this is a totally different issue.

Adding "stylesheets[all][] = css/components/misc.css" to our mytheme.info file appears to have worked as a workaround for the time being. Thanks naevehane.

I have reproduced this bug.
In 7.x-5.x-dev using css, not sass, with aggregate css turned on, the css from components/misc.css is indeed not used. The css from layouts/responsive.css *is* used. Using sass with aggregate css enabled works as expected, and using either sass or css work fine with aggregate css not enabled.

Ok. So this is a blocker for the release of 7.x-5.4. Taking a look now.

From this file:

/* HTML element (SMACSS base) rules */
@import "normalize.css";

/* Layout rules */
@import "layouts/responsive.css";

/* Component (SMACSS module) rules */
@import "components/misc.css";
/* Optionally, add your own components here. */
@import "print.css";

The aggregated file is automatically pulling in the contents of normalize.css and layouts/responsive.css, but it's not including components/misc.css or print.css. This is definitely a core bug. :-p

Investigating a work-around.

Here's the core bug: #1198904: drupal_load_stylesheet() fails to load @import files in different directories

There's no work-around except to not put CSS files into different sub-directories. :-p

Ok. So this is a blocker for the release of 7.x-5.4. Taking a look now.

Since this is a core bug with no feasible work-around (except stop putting the CSS files in sub-directories), I'm going to roll a 7.x-5.4 before this is fixed.

For this bug, you'll have to wait until Drupal 7 is fixed or apply the patch from #1198904: drupal_load_stylesheet() fails to load @import files in different directories

Awesome. Thanks JohnAlbin.

What is the reason for keeping the style sheets in various directories? Isn't it the obvious solution to just keep them in the main css directory?

@ naevehane:

I love you! You made my day!!!! I am almost crying! This problem almost killed me, and you solved it for me!!!!!!! Thank you so much!

#5 solution worked for me on Zen 7.x-5.4.

also this, which was easier fix: https://drupal.org/node/1198904

my style.css :

@import "normalize.css";

/* Layout rules */
@import "layouts/fixed.css";

/* Component (SMACSS module) rules */
@import "../components/misc.css";
/* Optionally, add your own components here. */
@import "print.css";

! - Added ../ to misc.css - !

Setting this back as #8 through #12 for proper pending fix.

Changing back to "Fixed":

I tested to see if this is still a problem,
and this is no longer an issue for either of
- Zen 7.x-5.x-dev
...or...
- Zen 7.x-5.4.

As I understand it,
this issue was related to a Drupal 7 Core 'bug'
that no longer exists.

Also:

Please note that Zen 7.x-5.4
is substantially different from Zen 7.x-3.2.

You must use the Zen base folder "zen" from Zen 7.x-5.4;
since if you are simply using
a copy of STARTERKIT from Zen 7.x-5.4
along with the Zen base folder "zen" from Zen 7.x-3.2
this problem will persist for you.