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

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

Ranko

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?

and

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.

Jonathan

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.

Jonathan

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!

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:)

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.

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
    </FilesMatch>

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

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.

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

Hello,

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.

Katy
Drupal Developer at SeascapeWebDesign.com

Update:
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

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

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.

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.

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.

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

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

thanks

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 ?

#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.

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

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!

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.

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.

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.

Hi

#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?
Thanks
M

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.

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 :)

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.

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.

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?

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.

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.

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.

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.*
</ifModule>

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

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

Patrick
www.PatrickOLeary.com

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.

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.

Thanks,

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.

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 built properly. Human error does occur more often than you think.

I know this is about D7 and I had problem with D8, but #6 fixed my problem. I post here just in case someone googles this issue.

My drupal core is 8.3.7 and the CSS and JS would not load if I enalbed "Aggregate CSS files" and "Aggregate JavaScript files" after I turned on SSL access via https://

If I tried to access the js file directly though url like this:
https://www.mysite.com.au/sites/default/files/js/js_zSR8QDzfe0ZfrHVr34kX...

Firefox complains:

Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

    Please contact the website owners to inform them of this problem.

Chrome complains:

This site can’t be reached

The web page at https://www.jtcm.com.au/sites/default/files/js/js_zSR8QDzfe0ZfrHVr34kXD2xlPaH3Ufs0hJYopBB1SoU.js might be temporarily down or it may have moved permanently to a new web address.
ERR_CONTENT_DECODING_FAILED"

Weirdly, IE loads OK.

I knew the Server API on the shared hosting is LiteSpeed V6.11, but I didn't know they have their own compression.

I've tried #13 and installed advagg still the same.

So commented out gzip compression and works OK now.

One of our problems was that we had syntax errors and typos in some of our custom CSS stylesheets. After fixing these errors, CSS aggregation worked great again.

As #45 mentioned, we have the exact same problem. When does it occur?

Enable CSS and/or JS compression
Your site is served through litespeed
Your site is served through HTTPS
You are visiting with a browser which returns TRUE on this rule (RewriteCond %{HTTP:Accept-encoding} gzip) IE/Edge doesn't. Chrome and Firefox do.

The problem is that by default litespeed compresses output. Because of the .htaccess rules, and returning TRUE on above mentioned rule, the request of the generated .css is redirected to to .css.gz without giving the extension. Probably then litespeed thinks - I get a .css, lets compress it!

The strangest part for me is, this doesn't happen when your site is served through HTTP.

We are looking into a solution, where no changes to the core .htaccess need to be applied.

Hi guys

Am working on Drupal 7 completed all most my project going on live server one day am install update Manager me module in live site Drupal modules then after I got css errors aggregator css advagg_css module issue

Lot of issue content time 404 error issue I don't know what's issue on live site many time I have deleted Drupal configuration performance css clear cache rebuild setting clear all cache . Setting but I got old css rebuild in my web site what is issue any one resolve my problem

Thanks
Alok Sr. Drupal developer
Skype. alok.mishra67

My hosting changed their server and suddenly this popped in.
Somehow gz-compressoin seems to be mis-configured.

To get aggregation without compression, using AdvAgg does the trick, see #13

Here was my solution for this same problem, which I was having just now on a brand new Drupal 8.4.4 installation. I didn't want to just disable aggregation (which is very useful and efficient) and leave it at that.

1. Un-check both "Aggregate CSS files" and "Aggregate JavaScript files". Reload one of the affected pages (which should be all of them, at least for me), and you should see everything return to normal.
2. Re-check both "Aggregate…" checkboxes. Reload the page and you will see the problem return.
3. At this point, I rebuilt the cache using drush cr, and reloaded the page. All CSS styling returned, with the checkboxes still checked.

#29 worked for me. Thanks!

At this moment, the issue is solved within our hosting stack. The ISP updates regularly and at some point we were able to enable compression again without issues.

Changelog of releases of litespeed do not point to resolving something around this issue: https://www.litespeedtech.com/products/litespeed-web-server/release-log

I'm on Drupal 8.4. This problem occured after having upgraded the admin-menu module. When aggregating the CSS files the CSS breaks and in the HTML source code i find this

<link rel="stylesheet" href="/?p4s1vp" media="all" />
<link rel="stylesheet" href="/?p4s1vp" media="screen" />
<link rel="stylesheet" href="/?p4s1vp" media="all" />
<link rel="stylesheet" href="/?p4s1vp" media="all" />

As you can see the href is just nonsence. I have used drush cc css-js and drush cr but to no use. What is this about?

Hans

I can confirm exactly the same problem as described in #53 on Drupal 8.5

Ok I finally found the fix on the system: The temp directory was not writable on that host. Check your logs and if the temp directory is set correctly under: /admin/config/media/file-system

Now compression of css / js works perfectly :)

I don't understand why this is not fixed yet. I do a clean install of Drupal 8.5.2 and same issue, no theming/css. I do want to use css aggregation and want to have a theme and I don't want to open up some directories to the www (chmod 777).

And again, it is a clean install, no module installed, the install script should set permissions correct. Should that not work out of the box?

What do I have to do?

I build / test on a isp server with.
PHP 7.2
MySql 5.6

Have set rewrite / in .htaccess.

Error log says:
/sites/default/files/.htaccess: Option MultiViews not allowed here, referer: http://www.domain.xx/admin/config/development/performance

My problem was the css that should override the default was added conditionally(in my case conditioned on language).
The result was the css not being loaded when aggregation was enabled.
Simply reading the documentation of drupal_add_css helped me a lot.
I had 2 options preventing this from working:
'every_page' set to TRUE because I misinterpreted it ( I actually wanted it on all pages, but only for certain languages )
'preprocess' has a default value of TRUE and it causes a css to be included in aggreation, problem being that if it is not loaded at the time the aggregated files get created, it will not be loaded at all afterwards.

Solution was: drupal_add_css(path_to_theme() . '/css/language-override.css', array('weight' => 101, 'preprocess' => FALSE));

After inspecting the .htaccess file, I got it working by removing this:

<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>

I am still going to dig a bit deeper to find out why, but for the time being, this solves my problem.

Worked!

I too was facing the same issue, after investigating a couple of hours, I tried the following which worked for me:

This is because of the syntax error in your CSS or JS files which is obstructing aggregation. I tried to validate CSS files one by one using online W3C CSS validator: https://jigsaw.w3.org/css-validator/ and corrected the syntax.

Note: After correcting the syntax, you need to uncheck aggregation and again checked and save it. Then, clear cache to test it, should work.

Thanks.

Hola, buenas, yo tengo un problema similar.

Verán, desde hace unos días comencé a utilizar Drupal 8 dentro de un proyecto para insertar una sección de noticias que pueda ser editable por miembros de la empresa donde trabajo actualmente.

La cosa es que bajé un template para importarlo a Drupal mediante la maquetación de acuerdo a lo señalado, me carga mi hoja de estilos CSS en la pagina principal (drupal.dd/) dentro de mi servidor Acquia, pero al agregar un artículo como contenido, evidentemente la página cambia por la siguiente: drupal.dd/node/numero_de_nodo y ya no me carga los estilos, he buscado mil formas de agregar mi css a todas las páginas en general y no me funciona, incluso utilicé el "global-styling" dentro de mi biblioteca del proyecto y no aplica los estilos para todos los nodos en mi website. Espero puedan guiarme a resolver ésto. Muchas gracias.

Hello MikooVR,

the Drupal community language is English! If you don't speak english, please use a translation service like deepl.com or google translate.
Please edit and translate your post instead of posting it again to keep the issue as short as possible. Thanks!

I too faced this problem and since I didn't find any answer that worked for me, I'll post it here.
So in my case aggregation somehow worked in dev environment, but not in stage or prod (hosted in Acquia Cloud). The problem was the temp folder path wasn't defined correctly.

To fix, add this snippet in settings.php:

if (isset($_ENV['AH_SITE_GROUP'], $_ENV['AH_SITE_ENVIRONMENT'])) {
  $config['system.file']['path']['temporary'] = "/mnt/tmp/{$_ENV['AH_SITE_GROUP']}.{$_ENV['AH_SITE_ENVIRONMENT']}";
}

Hope this helps someone.

Very late addition to this discussion, but there's another oddball thing that happens with aggregation turned on: url('') references stop working with a subset of relative directories.

If you're using relative URLs that begin with "../" to browse up a directory level to access another sibling directory (i.e. src: url("../img", etc.), it will work when CSS aggregation is OFF but stop working when it's ON. The compression strips out the ".." in front of the URL (likely for security reasons to avoid unwanted directory traversal).

You have to either use absolute URLs (bad idea, IMO), or use webroot-relative URLs (ex. url("/webroot/to/your/assetDir/img/etc."), or just don't reference anything outside of the CSS file's directory (or its children).

Very good ! NICE !

#13 it's work ! Done !

I had a similar problem with Aggregate CSS files and Aggregate JavaScript files (Drupal 8.7.7) check to comment this lines in .htaccess:

# 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]

But don't ask how it works because I don't know, my provider helped me to resolve it.

#59 (checking my css) worked for me.

One thing that broke the css was a google fonts import. It seems the semicolon that separates the different font weights in the google fonts url confuses the aggregator:

@import url("https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;700&display=swap");

So I changed it to this:

@import url("https://fonts.googleapis.com/css2?family=Open+Sans:wght@400&display=swap");
@import url("https://fonts.googleapis.com/css2?family=Open+Sans:wght@700&display=swap");

It only took me 3 hours to figure this problem out...but thanks to #59, I finally did.

Thank you #66.

Nothing else worked until I read that!

Enabling css aggregation would break my site layout- doing the research and seeing references to tmp location and .htaccess didn't give me a solution. But the reference to pre-processing did!
I use an antiquated module called Asset Injector - which allows me to build quick css and I use it to manage block related css overrides. In one such block, I had embedded Twitter, Facebook and Youtube blocks in the region. All three have references to external css and js. Disabling pre-process for this specific injector resolved my problem and allowed CSS aggregation to work on my site. Hope that helps someone.

Thank you #66.

Nothing else worked until I read that!

Remove the external url's like fonts and icon cdn's from main css file and include them into library file. thanks

Sometimes, the css file doesn't generate properly. If none of the above work then delete the files/css folder and drush cr.

Enabling css aggregation is also breaking the site. This is happening just after the deployment and sometimes at random to the front end as well as on the admin login. Below are the details for the drupal site -
1: Site is hosted on the azure with docker container.
2: The images and other files are saved on the azure blob container
3: Parent theme is bootstrap and we have used a custom child theme based on it.

Have tried below points but not succeeded -

1: giving 0777 to /tmp folder location.
2: checked the .htaccess file and have added all the points mentioned in above threads.
3: commented all the external font urls which was called in the main style file.
4: resolved all the css related bugs which was identified via the advance aggregation module in validation section.

Can anyone provide some more inputs/ways to resolve this issue.

Thanks in advance :)

What version of drupal? Which web server?

May be related to https://www.drupal.org/project/drupal/issues/3373929

or

https://www.drupal.org/project/bootstrap/issues/3369979

Reply on #73: The drupal version is 9.5.9 and the server which is configured is Apache2 on Linux machine via the docker and Azure portal. Thanks for sharing issue links but these are not related to my issue.

Ok, I would consider posting a new ticket as this one is for Drupal 10.x afaict

Also aggregated files are usually stored in public storage. Maybe check the permissions there as well.

Drupal has the following types of file storage:

tmp
public
private