CSS aggregration breaks site - how to troubleshoot?

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

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.

Answer 6

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 :

global-styling:
  css:
    theme:
      css/booswatch_flatly.min.css: { minified: true, preprocess: false}
      ...