I have created a sub-theme using:

drush zen "My Custom Theme" my_customtheme --without-rtl

The theme works nicely, however when I turn on CSS aggregation, the layout seems to break and some things are missing. For example, I have a Views pager and with aggregation on, the styles are lost for it. If I examine with Firebug, I can see that normally, it picks up this style from modular-styles.css

.pager {
clear: both;
padding: 0;
text-align: center;
}

... but if I turn on aggregation, I no longer see the CSS above being picked up. This leads me to believe that modular-styles.css is not being included in the aggregated files. I noticed that in styles.css, it says:

When you turn on CSS aggregation at admin/config/development/performance, all
* of these @include files will be combined into a single file.

... but I am thinking there is perhaps an issue with this. I am not really sure how to troubleshoot this since I am pretty new to Zen 5, I have mostly used Omega. Note that this issue happens in all browsers, it's not specific to any platform or version. I tested with Firefox, IE9 and Chrome.

CommentFileSizeAuthor
#4 zen-css_aggregation-1796726-6700710.patch1.18 KBdanny englander

Comments

Devline’s picture

Devline commented

I had some kind of similar issue, where almost all css files were not included during aggregation process. I finally solved the issue by declaring all the css files in the info file of the subtheme, except for the style.css file (which is used to import the css files).

It seems that aggregation processes only css files that are declared in stylesheets[all] array. I'm not sure if this is true or false, and if there is something I missed to do it the right way.

kari.kaariainen’s picture

kari.kaariainen commented

In styles.css (note that there is s for plural) prosessing stops at this line:

@import "layouts/responsive-sidebars.css";

No @import rules after this are being processed. What is wrong with that line, I don't know, except that it is the only line having a subpath.

Work-around:

If this line is deleted, all other rules work.

Also if the responsive-sidebars.css is copied to the same directory as the others (normalize.css, modular-styles.css etc.), and called accordingly, everything works.

So, this stops processing: @import "layouts/responsive-sidebars.css";
This does not: @import "responsive-sidebars.css";

echoz’s picture

echoz commented

@kari.kaariainen, I can not reproduce. With an almost vanilla subtheme, I tested just drupal css aggregation, then both sass production environment plus drupal aggregation, and I always had all the css used as listed in styles.scss.

I too take out the "layouts" sub folder, and I'm glad it works for you without it, but as I reported, all works with the default configuration as well.

@highrockmedia, if you are still having this issue, remember to clear caches while testing and post again if you still want help.

danny englander’s picture

danny englander
(he/him)
commented
StatusFileSize
new zen-css_aggregation-1796726-6700710.patch1.18 KB

Hi all, I tried something else and I moved this code in my sub-theme:

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

... to the end of the styles file and voila, all CSS aggregation works fine now. I have no idea why and what the ramifications are though, I don't really have time to do any kind of real testing as this was just a little freebie I was working on. I am attaching a patch not necessarily at all to be applied against the Starter Kit but just to show the theoretical code that was changed in my sub-theme. I am sure there are many reasons the code is where it is currently. Again this was my first Zen project so I don't know all the ins and outs yet, I have been using Omega mostly for a while now.

And as @echoz said, she cannot reproduce this. Probably my next thing would be to do all the plain vanilla tests again as well but I just don't have time right now so we should probably close this under "cannot reproduce".

echoz’s picture

echoz commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ramper’s picture

ramper commented

@highrockmedia, @kari.kaariainen: Thanks for that tip. I've been trying to stick with the Zen theme because of its "reputation" :). I too had that problem after turning on CSS aggregation and I never would have figured out that no @import rules were processed after the line "@import "layouts/responsive.css";" (I do not have the "responsive-sidebars.css" in my subtheme created using drush). I did not want to remove the layouts file, so I moved that line to the end. I too am not sure of the implications of doing this, but it seems to work.

KellyB’s picture

KellyB commented

@highrockmedia - Can you tell me 'very specifically' where in your sub-theme you moved this code to?

I have a Zen 7.x-5.1 and when I turn on aggregation of css files my main-menu and tabs are not displayed properly. I have all my stylesheets included in the subtheme.info file, I have moved responsive-sidebars.css out of the layout folder into the .css folder and modified the subtheme.info file accordingly. Still no avail.

I do not see a styles.css file in the css folder, where else would that be?

please advise

echoz’s picture

echoz commented

@KellyB I can't tell from your description what's causing your problem, but to answer your last question, styles.css is from the dev version.

danny englander’s picture

danny englander
(he/him)
commented

@kellyB - "... to the end of the styles file". (so it's last.) ... and as I mentioned, "I have no idea why and what the ramifications are though". Hope that helps.

ursula’s picture

ursula commented

I had a similar problem and was looking at this thread for an answer. Since the solution was somewhat different, I am adding it to this thread, in case somebody else is looking here.

When I turned aggregation on, Firefox and Opera were displaying the theme correctly. Safari and IE8 were ignoring some css statements, while displaying others correctly - mostly from the later css files.

The problem turned out to be a syntax error (a missing curly bracket in an otherwise empty statement) at the end of one of the files, so after aggregation, the interpretation of the subsequent files was somewhat erratic. Firefox and Opera were more forgiving.

mkindred’s picture

mkindred commented

I'm having this issue, too. I'm still using my old school Zen practices. I create a fresh.css file in my subtheme for all overrides. (And I'm not using sass.)

Here were my steps:

  1. Create subtheme via drush
  2. Create fresh.css in subtheme/css directory
  3. Add fresh.css via @import after layouts/fixed.css
  4. Add all overrides within fresh.css

Everything works fine before aggregation. But as soon as a turn it on, all my overrides are gone. In fact, all css files imported after layouts/fixed.css (components/misc.css and print.css) are broken. As mentioned above, aggregation seems to be stopping at the layouts/xxxx.css line.

My solution was to move fixed.css out of layouts directory:

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

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

/* overrides */
@import "fresh.css";

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

Now everything is working fine.

mkindred’s picture

mkindred commented

I spoke too soon. print.css wasn't loading. I had to move misc.css out of its directory, as well.

Garrett Albright’s picture

Garrett Albright commented

arsnova, I'm having a similar problem. Our problems seem to be related to this issue. Hopefully the next core release will contain the fix.

echoz’s picture

echoz commented
Issue summary: View changes
Status: Closed (fixed) » Closed (duplicate)

Duplicate of #2058113: choosing "Aggregate and compress CSS files" disrupts styling, and as noted in both Zen issues, is due to a core bug, resolved by the patch in #34 of #1198904: drupal_load_stylesheet() fails to load @import files in different directories