I have a number of D7 sites that "broke" recently when I applied 7.39 and a few other updates. By "broke" I mean the site's CSS styling completely disappeared. I can easily fix by disabling CSS aggregation, so I know that's the cause.

At first I thought it might be a Omega 3.x problem since all sites initially affected, but then a site based on Bootstrap had the same problem. (The CSS doesn't always break right away).

What steps can I take to troubleshoot to determine the root cause?

Edit - to add more detail based on Clive's questions below:

  1. Page source does contain <link>'s to aggregated CSS files (5 total)
  2. Aggregated CSS files do exist on server
  3. Status codes are 304 (4) and 200 (1)
  4. Folder permissions seem OK
  • maybe there is several reason for this problem but I think the aggregation cant create fie in public directory or you have a syntax mistake in one of your CSS files
    – Yuseferi
    Commented Aug 26, 2015 at 18:28
  • What were your "few other updates"? Commented Aug 26, 2015 at 18:38
  • I had 6 sites total break, and I believe the only updates in common with all were Drupal 7.39 and ctools 1.9
    – Dave Bruns
    Commented Aug 26, 2015 at 18:49
  • Is anything showing up as red or yellow on the Status Report?
    – mpdonadio
    Commented Aug 26, 2015 at 20:11
  • Status report looks good.
    – Dave Bruns
    Commented Aug 26, 2015 at 21:13

6 Answers 6


Some initial things to check:

  • Clear the cache (if you're running advagg, clear its cache). You can end up with stale file references sometimes.
  • Find out what's happening to the missing CSS:
    • When the styles go missing, does the page source contain a <link> to an aggregated CSS file? If not, check for modules/themes implementing hook_html_head_alter(), hook_css_alter(), or hook_preprocess_html(), and see if they're doing anything strange.
    • If the source does contain the <link>, what status code is the browser returning for the request? 404? You might have a stale cache issue. Clear all caches including those on any reverse proxy you're running. It might easily be something else, would require more intimate debugging. 500? Check the server logs, that should give you clues as to where things are failing.
    • If it's 200, does the requested file actually contain the styles it's supposed to? If not, you might be looking at a cache issue again, or potentially an issue with build tools (Compass/Gulp/Grunt/etc).
  • Switch the theme to a core one. Does it have the same problem? If so, it's probably a module or server setting at fault. If not, it's likely to be a problem with the theme.
  • Make sure permissions for your files folder are at the right level - the web server must be able to write to that folder to store the aggregated files. This is less likely to be an issue if the files are being created successfully, but it's worth double-checking you don't have an intermittent file system issue (if it's over NFS for example)

Getting the answers to those questions will help to narrow down the source of the problem, but unfortunately it's difficult to give specific advice as to where you should look in the code, as there are a lot of points problems could occur, and a lot of different modules you could have installed, at varying versions.

  • Great list, Clive, thanks. I've got a new problem now in that I can't reproduce (so far). What's odd is that it was reproducible a few days ago when I first discovered.
    – Dave Bruns
    Commented Aug 26, 2015 at 19:10
  • @DaveBruns - Most likely a cache issue. To avoid missing css in the future the advagg module should be used.
    – mikeytown2
    Commented Aug 26, 2015 at 21:26
  • I was able to reproduce on one site and added some more info above. @mikeytown2 - I've had advagg recommended before and will take a look - thanks.
    – Dave Bruns
    Commented Aug 26, 2015 at 22:01

I had this happen recently on a Backdrop site and had to really dig around to find the answer. Adding it here in case anyone else runs into this and none of the other answers here solve it.

As @Doomd writes here, using @import with Google fonts can cause the aggregation to break, apparently due to semicolons in the URL.

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");


I am experiencing this problem as well. I'm adding a new answer since I don't have enough reputation to comment on Clive's response.

I don't have a final fix for this, but I have found the following:

  • The CSS from my theme (plus the base theme and module CSS) is being aggregated and loaded into the page as I would expect. I can inspect it in Chrome's development tools and confirm that it's there.
  • However, only the CSS from the first CSS file in my theme is actually being applied. I'm using Adaptive as a base theme, so this means global.base.css.
  • If I copy my CSS overrides into this file, they are applied to the site. This is a fix of sorts, since it now allows me to aggregate the CSS without any problems. It's an imperfect fix since the issue/bug remains.
  • The issue relates to core CSS aggregation. Installing Advagg neither helps nor hinders.
  • I ran CSS validation on my CSS overrides. I didn't see any showstoppers. However, the fact that the code works fine in the first CSS file listed in my theme's info file but not in the fifth file when aggregation is enabled, suggests it probably isn't a validation issue.

One possibility is that there is a bug in AdaptiveTheme that breaks when D7.39 and/or CTools 1.9 are installed. I haven't ruled that out yet. But I have other sites with this combination that are not affected so I'm disinclined to point the finger at AdaptiveTheme.

I'm now working through the modules installed on this site and a similar site that isn't affected to try and find a module that might be causing the problem.

  • After further investigation, it appears that there is one CSS file in my theme that is causing the problem. This file is the second file in the theme. I tried moving my other CSS files above this file, and it seems to have resolved the issue. Commented Aug 30, 2015 at 0:39
  • The file causing the issue is global.style.css, which is part of at_subtheme. I replaced it with the original file from at_subtheme, which also resolved the issue. So at this point, I'd say it's some faulty CSS in my copy of that file, which I now need to track down and remove. Commented Aug 30, 2015 at 0:50
  • That sounds like a bad bracket somewhere.
    – Les Lim
    Commented Sep 2, 2015 at 5:03
  • Thanks ... yes, it turned out I'd transposed a ; and ) in a single line of code. Commented Sep 17, 2015 at 5:22
  • Similarly, I just experienced this due to an unclosed comment at the beginning of a file (which itself only contained a few styles that were overridden elsewhere, so the fact that those styles weren't being applied wasn't apparent.) So checking for invalid code is definitely worth doing. Commented Sep 20, 2019 at 23:38

Problems with aggregated CSS files are very often because of unclosed or mismatched curly brackets in one of the individual files.

When there is an unclosed curly bracket in 1 out of 15 CSS files, the error is limited to that file, and some browsers will assume the closing bracket at the end of the file. The other 14 correct CSS files will apply normally.

When those 15 CSS files are concatenated together through aggregation, that unclosed bracket now contains all of the style rules that appear after it. They will not be evaluated.

You may want to check each individual CSS file. A linter or a good IDE with error highlighting can work wonders.


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

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

I think that the aggregation module also tries to compress files. So by having this in the htaccess file, you are gzipping twice. I THINK. I could be wrong. Either way, this solves it.


I stumbled upon this with D9, trying to add a css resource to a library.

I eventually solved it adding a couple of properties to that css :

      css/booswatch_flatly.min.css: { minified: true, preprocess: false}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.