I have built a custom theme using zen.
For my image galleries, I have code in the "fields.css" file for my theme, to float my images left.
It works fine as long as aggregate and compress css files is turned off.

As soon as I turn this on, the css no longer is showing in firebug, and my css is not applied any longer, and my images are no longer floated left.

This seems to be a bug, please advise, as I would like to use this feature.

#10 1335366_no_gzip_ie_do-not-test.patch759 byteszoo33


Ranko’s picture

Status: Active » Postponed (maintainer needs more info)

Are you using a subtheme of Zen? Did you register your fields.css properly in theme.info?


jgeist’s picture

Hello - I also lose css when "Aggregate and compress CSS files" is checked. I don't want to hijack acetrebo's thread, but starting a new issue report with exactly the same title / issue description seemed silly, and I also think this is a drupal issue - and not something related to any specific theme.

I currently maintain two drupal 7 sites, and am building a third. Theming and styles work fine in all of them so long as I do not check the aggregate and compress CSS / JS checkboxes. If either (or both) are checked, there is no css being loaded in Internet explorer (I've tested against IE versions 7, 8, 9).

All other browsers I've tested (so far) work fine (firefox, chrome, konqueror).

I've read many of the other threads on this issue, and they mostly get closed and marked fixed, but I've verified that the problem still exists in a clean install of Drupal 7.12 (no modules added, no themes added, no content added - just a brand new clean install). The first thing I did was enable aggregate and compress, and IE does not load CSS - other browsers do.

(For those who just can't wait to jump in with the 31 file import limit problem in IE - all of my sites work just fine with aggregate and compress off - this is not the problem here).

When I save the served page locally, and manually download the css files (editing the urls in the local copy of the page), IE will load *some* of the css, but not all - things get funky, blocks sitting on top of each other, etc...

I have verified that my .htaccess has the following lines:

      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

and my thinking is that if it was a server (or file permissions) issue, wouldn't it affect *all* browsers?

I have tested the sites from different computers - just to make sure there wasn't some local setting breaking IE.

I guess I have two questions:

1. What should I try next to diagnose the problem? IE does not seem to be very forthcoming with what it doesn't like - does anyone know of any good plugin/addon for IE similar to firebug or web developer for FireFox?


2. Maybe there should be a documentation page/wiki added for site developers on how to make drupal pages render properly in IE?

honestly, I wish I could just make IE go away and concern myself with FireFox, Chrome, and Safari/Opera/Konqueror.


jgeist’s picture

After a lot of further investigation, I believe I've isolated part of the problem. It seems that my hosting provider is using Nginx / Varnish as a reverse proxy - phpinfo() shows apache2 as my server, but inspection of the http headers shows Nginx / Varnish. My provider does not mention nginx or varnish anywhere in any of the online documentation they provide, and the server information page on my account no longer has any information on what server is being used - the thing about cheap webhosts? I guess you get what you pay for.... :-/

It seems that Nginx provides its own compression. My .httaccess file does use set Content-encoding instead of append, so the headers are coming down correctly, but when Drupal and Nginx are both providing compression, the encoding on the css files is set to x-gzip instead of just gzip. While I realize that this shouldn't be a problem, IE cannot figure it out, and css and js files remain gibberish to IE - so the result is that css is ignored, and js gives invalid character errors.

Since every get request adds time to the page load, I still would like to use the aggregate features to speed things up. Also, since Nginx / Varnish is going to compress everything anyway (I have no idea how or even if I even can change its settings, (the only way I even know it's in the loop is by looking at the headers being served) I don't want to waste time compressing things in Drupal. I've experimented until arriving at the following solution:

1. Both "Aggregate and compress CSS files" and "Aggregate JavaScript files" are checked.

2. "Compress cached pages" is not checked.

3. The whole block in the .httaccess file for compressing files is commented out (see below).

  # Rules to correctly serve gzip compressed CSS and JS files.
  # Requires both mod_rewrite and mod_headers to be enabled.
#  <IfModule mod_headers.c>
#    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
#    RewriteCond %{HTTP:Accept-encoding} gzip
#    RewriteCond %{REQUEST_FILENAME}\.gz -s
#    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
#    # Serve gzip compressed JS files if they exist and the client accepts gzip.
#    RewriteCond %{HTTP:Accept-encoding} gzip
#    RewriteCond %{REQUEST_FILENAME}\.gz -s
#    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
#    # Serve correct content types, and prevent mod_deflate double gzip.
#    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
#    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
#    <FilesMatch "(\.js\.gz|\.css\.gz)$">
#      # Serve correct encoding type.
#      Header set Content-Encoding gzip
#      # Force proxies to cache gzipped & non-gzipped css/js files separately.
#      Header append Vary Accept-Encoding
#    </FilesMatch>
#  </IfModule>

My site now works the same in IE as in FireFox - style sheets load and work properly. The number of requests for each page load has been reduced from around 18-31 to about 12. Pages load in about half the time they were before.

Now - for all the experts out there - are there any issues I should be concerned about from commenting out that block in the .httaccess file? I'm not an expert on this, but it appears to only be for compressing css and js, and hence is redundant since Nginx is compressing everything it can already.

For others having issues with css in IE when aggregate is on - take a look at http://web-sniffer.net/ and look at your http headers when aggregate and compress is off. If the headers are still showing the content is being compressed, you probably have the same issue.


erin814’s picture

Version: 7.9 » 7.14

Thanks jgeist... I just spent 5 hours trying to figure this out and finally found your thread. Your solution worked for me perfectly. Thanks again!

jooblay.me’s picture

Another note on this issue we found:)

Symptom: checking this box makes the css can be lost on all pages. Path:/admin/config/development/performance
Aggregate and compress CSS files.

Symptom: Checking this box makes the admin menu and other .js script get lost and scrambled. Path:/admin/config/development/performance
Aggregate JavaScript files.

both of these issues seemed to be caused from directory permissions in the sites/default/files/css The css directory needs to be chmoded 777 (LINUX LAMP^ SERVER) [command line: chmod 777 sites/default/files/css] and or on cpanel setting this file permission to 755 fixed all this. It seems this issue comes up when moving or copying sites from one site to another. Example would be copying a live site at example.com to your development site on your server of a subdomain on cpanel. Either way by fixing the file permissions this is fixed.

Hope this helps:)

spacez320’s picture

Status: Postponed (maintainer needs more info) » Fixed

This is probably the fix that most people are looking for if they come here -- setting full write/read permissions (777) on the sites/default/files/css/ directory so that the webserver can use it.

eclecto’s picture

Turns out I'm dealing with exactly the same problem (the hidden stealth Nginx / Varnish header). I wouldn't suggest blocking the gzipping entirely. I've compared and the filesize and the gzipped/x-gzipped versions of the CSS/JS files are still significantly smaller.

I was able to solve the problem by attacking the root directly: if the user agent identifies the browser as IE, ignore the gzipping rewrites.

  # Rules to correctly serve gzip compressed CSS and JS files.
  # Requires both mod_rewrite and mod_headers to be enabled.
  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteCond %{HTTP_USER_AGENT} !MSIE
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteCond %{HTTP_USER_AGENT} !MSIE
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

It's the best of both worlds. Non-IE browsers get to download smaller files and IE gets to not break.

Status: Fixed » Closed (fixed)

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

endless_wander’s picture

I love the Drupal community so much.

I was encountering this issue for an inherited website and had no explanation. Now, I look like a genius for my client. :)

For the record, the website I had the problem with was hosted on Netfirms.

zoo33’s picture

For those who want to use the workaround described in #7, here's a proper patch.

katy5289’s picture


I'm using Reseller - Shared hosting at Hostgator.com. I'm using Drupal 7.24 and when I enable Aggregate and Compress CSS files, all site styling is lost. This happens in Firefox, Chrome and IE.
When I enable Aggregate Javascript files, I lose my Admin menu.

I've tried all the suggestions I found on Drupal.org
- sites/default/files/css has permissions 777
- the tmp directory is /tmp. I changed it to home/username/tmp and still had the same problems.
- I tried various edits to the .htaccess file but nothing worked.
- I tried Garland theme, but the same problem happened.
- Can anyone provide insight to fix this problem?

Note: This problem does not happen on my local development server.

Drupal Developer at SeascapeWebDesign.com

katy5289’s picture

Issue summary: View changes

My web host tech support confirmed that they are running Nginx on my shared hosting server at Hostgator.com. However, my situation is a bit different than jgeist, I didn't have problems with IE but with Firefox and Chrome.

I was able to solve the problem by removing the new .htaccess files recommended by Drupal 7.24 for the files/css and /tmp directories
- After I removed the .htaccess file from home/username/tmp, my admin menu came back when Aggregate Javascript files was turned on
- I also removed the .htaccess file in sites/default/files/css and then my site styling came back when Aggregate and Compress CSS files was turned on.
- Compress Cached files is also turned on.
- I used the root .htaccess file from Drupal 7.24

gmrmedia’s picture

If these solutions do not solve the problem with CSS aggregation, try this:

  • Install this module: advagg
  • Enable new module
  • Go to: admin/config/development/performance/advagg
  • Disable option: Create .gz files and save configuration
  • Go to: /admin/config/development/performance and turn on CSS aggregation
MissterX’s picture

Addendum to #13 (gmrmedia):

  • remove all files in "sites/default/files/css" alt. "js"

Neither the web GUI nor "drush cc all" seems to remove those files.

Oops, to hasty. Did not work, sry.

webby7097’s picture

Thanks all for your comments here; I had an issue with only my image resizing css not working if aggregate and compress CSS and/or aggregate Javascript were enabled. If I disable Compress cached pages, I can enable the other two and everything is working and running quicker.

sidharthap’s picture

I am facing the same situation but here is my situation.
1 - In production environment i have Varnish cache enabled and drupal page cache. js, css cache enabled.
2 - i have slider content coming through views and flexisliders.
3 - Some times the slider content shows disturbed in all browsers.
4 - I debug using FF web developer tool and it seems the JS required for sliding is not available on page.
5 - After clearing Varnish cache 2 3 times resolves the issue.

I am not able to replicate the same in development environment. It is only causing in production. Any help would be appreciated.

ericbobson’s picture

+1 for gmrmedia's solution in #13. That solved the issue for me. Thanks.

ravi_admec’s picture

hey #13
it is amazing,, i am happy, really my site got better performance.
i was facing this issue from last several days.


Philou88’s picture

Got some problems in "sites/default/files/styles/..." to include pictures with Colobox.
"IfModule mod_headers.c" in '.htaccess' was the reason because I used 'Compress cached pages', 'Aggregate and compress CSS files' and 'Aggregate JavaScript files'.
To do not use "IfModule mod_headers.c" in '.htaccess' and to continue to use Colorbox, thanks for #13, works nice with the module 'advagg' and options 'bundler', 'CSS compression' and 'JS compression'.
The parameters of 'advagg' are a little bit complex.
Is anyone found a tutorial ?

knalstaaf’s picture

#13 works for me as well, and I don't need to have Create .gz files disabled apparently.

Edit: I found what caused the issue (a conflict with a white-space style for some reason), so I don't need to use this module after all, and can go with the core aggregation method.

jomarocas’s picture

hi #13 no working for me, and #20 is probable in bootstrap 1, but dont see the solution here, i find the solution because is only when compress css but js working good, thanks if any idea

Drupingo’s picture

Hi there! I had the same issue today. My Solution is as follows:

My Path to Public File System is "site/default/files"

Step 1: I gave the following permissions:

site -> 755
site/default -> 755
site/default/files -> 775

Step 2: Disable CSS/JS Aggregation and save Configuration
Step 3: Clear all caches
Step 4: Enable CSS/JS Aggregation and save Configuration

Everything works fine for me now!

attilahooper’s picture

I'd like to note on a fresh install of D8 I had the same problem where theme was broken. It was because initial permissions were not correct. The solution #22 which Drupingo provided worked for me. Although I did more thorough with fix-permissions script. So maybe it's not a good idea for caching to be enabled out of box.

wubuer’s picture

maybe you can try this free online css minifier, i used it for a long time, it doesn't lost any style while page loading.

pachabhaiya’s picture

I had the same problem.

This solution worked for me.
1. Deleted sites/default/files/css and sites/default/files/js folders.
2. Created sites/default/files/css and sites/default/files/js folders again.
3. Changed permission of both css and js folders to 777.

marzie’s picture


#22 and # 25 did not work for me

php 5.5.31
clean drupal 8.0.2 install on shared host.
which also is having install ftp issues.

any other ideas?

capogeannis’s picture

In my particular case, it looks like it's something to do with the handshake between our site and how it is served up through our CDN. It's a mess of a situation for me to debug as that other end is only accessible by our Operations team. For now, I've just left the feature unchecked.

Run the site without the CDN, no problems.

martinterryevans’s picture

I had similar problem with CSS aggregation which turned out to be a simple syntax error at the end of my custom.css file
Run your css thru a validator like http://codebeautify.org/cssvalidate - worked for me :)

joelhsmith’s picture

I think the root of the problem here is not Varnish, but a Lexical error in the CSS.

What is a Lexical error you ask? In my case my Lexical error was an invisible special character inserted into the SASS or CSS file. Invisible characters are hard to find because they look like spaces.

In your local (non-Varnished) environment it will cause no problems. But it is technically a syntax error. When Varnish gets to it it will skips over it leaving out a selector or property, then moves on. The invisible special character changed into a question mark "?". So the selector that was ".foo" is now "?.foo". "?.foo" will never match anything, making it appear that the style has been left out, when it is actually the selector that changed.

You will need to run your generated CSS thru https://jigsaw.w3.org/css-validator/validator to find which line the error is, because it might be invisible.

Also, if you are using SASS with Sourcemaps, the comment at the bottom of each CSS file
/*# sourceMappingURL=foo.normalize.css.map */
could cause one of these lexical errors to get introduced.

allenthehusband’s picture

Thank you martinterryevans (#28). It was an unclosed bracket that was tripping me up. The validator at: https://jigsaw.w3.org/css-validator/ helped me track it down.

fchandler’s picture

Why is this marked closed and fixed when it is clearly not. I have three sites, on a shared server, that all the solutions are not working. Tried changing .htaccess, adding the advagg module, and changing permissions. I ran the sites through https://jigsaw.w3.org/css-validator/ that produced all kinds of errors and warnings, most of which were in modules that have there own css files.

So how do I fix this?

joelhsmith’s picture

Are you using plane Compass, Grunt, Gaurd, or Gulp to compile the sass?

If it is indeed an issue with a different modules CSS you might need to open an issue in that queue instead.

capogeannis’s picture

I'm in the same boat. No lexical errors in my personal CSS. Any recommendations on a quick tool to do an across the board site CSS check? - of course, I'll have to filter through the countless warnings etc.... fun.

joelhsmith’s picture

If you think it is not your own CSS and that it must be some other module causing the problem there is an easy (but little known way) to exclude individual modules CSS.

Go to /admin/appearance/settings/YOURTHEME (I am using Omega 4 so it might be in a slightly different spot for you)
Scroll to the bottom you will see an "Assets" tab. Scroll to the bottom and you will find an "Exclude CSS files" text area. Just load the path to those files there.

I am very skeptical that the issue is coming from a different module, but that is a way you cat test your hypothesis.

Back to your CSS. To help you debug this situation it will be important to know what type of SASS compiler you are using. For example: If you are using Grunt for dev but choose to use Compass to compile your SASS for prod like thiscompass compile -e production --force will produce different css than Grunt build. One might leave comments in, one might take them out. Same goes for any compiler. I had a project a while ago that gave me a problem similar to you. When I compiled my Grunt project with Compass it thru the same error.

fchandler’s picture

All these sites are D7.43 with all modules and themes up to date.
The server is: Database system version: 5.5.46-0ubuntu0.12.04.2-log, PHP: 5.3.29, Web server: Apache/2

http://theochandler.com uses a subtheme of Bootstrap https://www.drupal.org/project/bootstrap no compiler
http://nellchandler.com uses a subtheme Omega 4 and compiled with Compass
http://franks-test.com uses a subtheme of Nexus https://www.drupal.org/project/nexus no compiler
These are all separate installs, in separate directories, in my root directory.

I contacted the hosting provider to make sure they did not have issues like the Nginx (or Litespeed, had an issue there previously). They added this for in an .htaccess in my root directory. It did not change anything. And it is really IE that is having the issue. Works as designed in Chrome and Firefox.

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
ggza’s picture

Hi! I recently had the same issue with IE8. The #13 resolved my problem.

pmol123’s picture

Re: "Style lost when using "aggregate and compress css files".

For weeks I have been wrestling with this same issue of my site (www.expertwitness.com) losing it's css style. Quite frustrating!

I too disabled the gzip of files as outlined in #13 and now it works. Yea!

See Solution Screencast Video: https://youtu.be/eDRZzQg26-Q


pmol123’s picture

pmol123’s picture

martinterryevans’s picture

2dareis2do’s picture

Following tips here and mainly making sure owner and group is same as that used by other files in directory - otherwise permissions will not work above (drupingo) and you will receive page with out styling and a tmp directory full of files that can not be saved to public folder.

ricky93’s picture

What if I uncheck aggregate CSS files within config/development/performance? When I uncheck it I see style! when I check it I dont see style! I do not want to break anything if unchecked.


jradpog’s picture

I struggled with this for a few hours trying every suggestion. In the end I found this: https://www.drupal.org/node/581558 It was as simple as not properly specifying the tmp directory at /admin/config/media/file-system. My issue was because I had moved the site to a new server and not changed the tmp directory. I just changed it to /tmp and it worked. This might work for others who have tried everything else to no avail.

bisonbleu’s picture

Stumbled on another reason why aggregation breaks CSS. But it's not something you would normally expect.

As it turns out for a website I inherited recently and which is running on Adaptive Themes, I found 2 duplicate sets of css buried at two different levels in sites/default/files that, when aggregation is turned on, were overriding the sites/all/themes/my_theme/css/... I was working on.

Don't assume everything is normal and build properly. Human error does occur more often than you think.