The modifications made in this release of Drupal (6.19) to CSS optimization lead to the following behaviour on my websites:

If CSS Optimization is ON
-> no stylesheets are applied to all browsers, but the files are still loaded

If CSS Optimization is OFF
-> only IE has issues (as expected)

For a temporary fix, you could just reverse the drupal_load_stylesheet function to 6.17 version in file "includes/", line 1996:

function drupal_load_stylesheet($file, $optimize = NULL) {
  static $_optimize;
  // Store optimization parameter for preg_replace_callback with nested @import loops.
  if (isset($optimize)) {
    $_optimize = $optimize;

  $contents = '';
  if (file_exists($file)) {
    // Load the local CSS stylesheet.
    $contents = file_get_contents($file);

    // Change to the current stylesheet's directory.
    $cwd = getcwd();

    // Replaces @import commands with the actual stylesheet content.
    // This happens recursively but omits external files.
    $contents = preg_replace_callback('/@import\s*(?:url\()?[\'"]?(?![a-z]+:)([^\'"\()]+)[\'"]?\)?;/', '_drupal_load_stylesheet', $contents);
    // Remove multiple charset declarations for standards compliance (and fixing Safari problems).
    $contents = preg_replace('/^@charset\s+[\'"](\S*)\b[\'"];/i', '', $contents);

    if ($_optimize) {
      // Perform some safe CSS optimizations.
      $contents = preg_replace('<
        \s*([@{}:;,]|\)\s|\s\()\s* |  # Remove whitespace around separators, but keep space around parentheses.
        /\*([^*\\\\]|\*(?!/))+\*/     # Remove comments that are not CSS hacks.
        >x', '\1', $contents);

    // Change back directory.

  return $contents;

css file.zip3.26 KBamandah
#25 881132-D7.patch804 bytesGarrett Albright
PASSED: [[SimpleTest]]: [MySQL] 22,853 pass(es).
[ View ]
#25 881132-D6.patch1.47 KBGarrett Albright
#12 881132.patch803 bytesGarrett Albright
PASSED: [[SimpleTest]]: [MySQL] 22,821 pass(es).
[ View ]


mcarrera’s picture

Same problem here. Thanks for posting it, but unfortunately using the old version of the function doesn't fix my situation.
Disabling CSS optimization partially solves the problem, as some style sheets are loaded, while others are not, but at least the site is usable.

HLopes’s picture

Here it solved the problem.

If CSS optimization was on, the layout would be broken with all browsers, if turned off it would only break in IE (as it normally does, because of the limits IE imposes in the number of loaded css)

If you have cache turned on, try to clear it after replacing the function, so it regens the pages in cache.

Julien Verkest’s picture

Same problem...

hsudhof’s picture

The problem seems to be a combination of non-latin chars in CSS comments and the PCRE configuration.
I am able to reproduce on one server where a CSS comment has an umlaut , i.e.

/* Anfänge */

With that line in the file, this yields an empty String:

= preg_replace_callback(
"<$double_quot|$single_quot|$comment>Sus"// Match all comment blocks along
"_process_comment",                         // with double/single quoted strings
$contents);                                 // and feed them to _process_comment().

EDIT: correction - the problem was that the CSS file was not UTF-8 encoded, but in ANSI/Latin1. Converting the file to UTF-8 resolved the issue.

HLopes’s picture

That could be the case, i've been checking my stylesheet and it has some commented tils (~) and strange chars ( �� - should be ç ).

EDIT - here it is encoded in ANSI.

introfini’s picture


Damien Tournoud’s picture

Version:6.19» 7.x-dev

I can confirm that the regular expression fails when non UTF-8 characters are fed to it. Not sure why we need the Unicode modifier here. It seems that it might be an oversight.

Bumping to D7 for further study.

Julien Verkest’s picture

I've passed all my ANSI css files to UTF-8 and it works perfectly. Thanks husdhof.

himue’s picture

While this comments tlaking anout Drupal 7, the same Problem exist under Drupal 6.
Solution here is also to convert the CSS-Files to utf8-format.

Garrett Albright’s picture

Title:CSS Optimization breaks CSS» CSS Optimization breaks with non-UTF-8 .css files
Priority:Normal» Major
Status:Active» Needs review
new803 bytes
PASSED: [[SimpleTest]]: [MySQL] 22,821 pass(es).
[ View ]

D7 patch attached. Haven't tried, but I suspect it'll apply to D6 too. It basically removes the u modifier from the regular expression. There may be a reason that the pattern had it in the first place, though…

dddave’s picture

Issue tags:+needs backport to D6

adding tag

xjm’s picture

Version:6.19» 7.x-dev

Dret: disable CSS optimization to fix the problem quickly. Then, re-save your CSS files in utf8, or try the patch above which Garrett Albright notes may work for D6.

It's marked as need backport to D6, so you don't need to change the version.

bleen18’s picture

Status:Needs review» Reviewed & tested by the community

Ok ... so the "u" modifier was first added here without any explanation (plenty of explanation about the "s" modifier though).

In fact there is no mention of it anywhere in that entire issue... That said, it doesnt look like it was added as a result of an obvious problem that is caused without it.

I've tested the patch in #12 on both D7 and D6.19 and I cant see any problems. I can say that this does fix my borked (read missing) style.css from the aggregated css file

blecheimer’s picture

I can confirm the problems mentioned in #4 with german "Umlauten" "Ä,Ö,Ü" after i have replaced them, everything was fine... thank you!

Lloyd’s picture

I've got way too many css files across multiple sites to save each of them in utf-8 coding. I tried to apply the patch but in 6.19 but it failed. I reviewed the patch manually and don't see the corresponding lines in the file that should be edited (thus explaining the failure).

Edit: I also tried manually editing the per the code in the OP and that had unexpected results (part of the page displayed correctly, part not). Also, in my case on one site I did try to save as utf-8 and I still had issues.

bleen18’s picture

@Lloyd just to clarify, the patch in #12 was created against D7 and does not apply against D6 ... once this gets committed to D7 we can create a patch for D6.

Making the change manually should have worked. Can you try these steps:
1) change that one line of code in manually
2) turn off css aggregation
3) clear cache
4) turn aggregation back on
5) clear cache
6) make sure you hard refresh your browser so you dont get locally cached css files

I really sounds like this is working, but your getting some cached css somewhere.

Lloyd’s picture

Sorry for the misunderstanding. As soon as I looked at the patch manually it was obvious it wasn't for D6.

And yes, when I made the changes to the one line in that needed to be changed everything worked just fine. I thought I posted that back here but I guess I didn't save it or something. But yes, easy fix.

Garrett Albright’s picture

new1.47 KB
new804 bytes
PASSED: [[SimpleTest]]: [MySQL] 22,853 pass(es).
[ View ]

D6 patch (untested, but it's pretty much the same change as the D7 one…), plus a new D7 one which makes the comments line up again whitespace-wise.

bleen18’s picture

White space fix in D7 patch == cool beans.
This patch still works as advertised and I still cannot find any adverse effects to removing the "u" modifier.

The D6 patch == highly neato.
As with D7 patch this change solves the aggregation problem with no visible side effects. Whitespace looks good too.


chx’s picture

Did anyone test with CSS containing multibye UTF-8 sequences? Rather, Did anyone analyze the preg whether it'll break? Since when does Drupal support non-UTF-8 anything? There are heavy questions to be answered.

Garrett Albright’s picture

I reverted the patch, then typed some Japanese into a CSS file and saved it as Shift-JIS. The same issue occurred. Saving the file as UTF-8 (hence a multibyte UTF-8 sequence), or re-applying the patch, fixed the problem as expected.

Since when does Drupal support non-UTF-8 anything?

Well, apparently we did before #444228: Optimize CSS option causes php cgi to segfault in pcre function "match" made it into core. Now we have people with broken sites. If we don't want to support non-UTF-8 anything, we can just ignore fixing this issue in D7, but I think we at least need to fix this in D6.

Dries’s picture

I'd still like to see a better explanation as to why this change fixes the problem.

Can someone point us to the documentation for 'u' on

bleen18’s picture

@dries: I cannot find much... mentions the "u" flag towards the very bottom of the page

I also found this info being quoted from but I cant find it on

This modifier turns on additional functionality of PCRE that is incompatible with Perl. Pattern strings are treated as UTF-8. This modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5.

Other than that I'm stumped to find more docs...

Heine’s picture

I don't see it documented so we can only conclude from comments and observed behaviour:, comment by hfuecks (emphasis added) describes behaviour:

1. If the pattern itself contains an invalid UTF-8 character, you get an error (as mentioned in the docs above - "UTF-8 validity of the pattern is checked since PHP 4.3.5"

2. When the subject string contains invalid UTF-8 sequences / codepoints, it basically result in a "quiet death" for the preg_* functions, where nothing is matched but without indication that the string is invalid UTF-8

I've conducted some tests with invalid bytes in UTF-8 subject strings; preg_replace always returns an empty string on such subject strings.

Any byte > 128 that's not in a multibyte sequence is invalid in UTF-8. That means that ASCII/latin-1 encoded CSS files containing > 128 bytes result in an empty preg_replace result.

As the characters matched by preg_replace are all in the < 128 range where UTF-8 and ASCII/latin-1 correspond and none of those single byte sequences are a subset of multibyte sequences, the UTF-8 mode is not needed.

Removing UTF-8 mode restores old behaviour. I do however encourage to declare only UTF-8 supported. After all, the fact that "it works" is purely coincidental and other character encodings are not supported at all.

Garrett Albright’s picture

Removing UTF-8 mode restores old behaviour. I do however encourage to declare only UTF-8 supported. After all, the fact that "it works" is purely coincidental and other character encodings are not supported at all.

Your idealism is admirable, but we've broken peoples' sites with a point release. I reiterate my above idea; perhaps we can remove the "u" for D6, but leave it in for D7 and force people to convert their stylesheets to UTF-8 encoding when they upgrade.

Also, note that we haven't heard of anybody complaining about this same problem happening with JS aggregation…

Damien Tournoud’s picture

Heine is just saying that because we remove 'u' doesn't mean that we support non-UTF-8 stylesheets. We don't.

Let's get #25 in.

Heine’s picture

@Garrett, as DamZ points out; I'm in favor of restoring the old behaviour, which is why I went to the trouble to explain why we can remove the 'u' modifier without any expected problems.

The old behaviour then "works" again, but is still not supported (there's a difference between those).

Dries’s picture

Version:7.x-dev» 6.x-dev

Committed to CVS HEAD. Moving to Drupal 6.

Ashford’s picture

I ran the D6 patch and there was no change. Cleared Cache and no change. I opened the file and verified the lines edited by the patch.

Is there another step I am missing? If not, can you redirect me to a beginner tutorial on how to convert the css files to utf-8? I have seen a line referring to UTF-8 at the top of a regular HTML file, but not a css file.

Garrett Albright’s picture

Ashford: Are you sure the patch was applied correctly? Try applying it again - if you don't see a message saying "it looks like this patch was already applied," then it probably wasn't applied correctly the first time.

As for how to convert the CSS files manually, it will vary depending on which text editor you're using… Surf the menus (presuming you're using a GUI one) for an item that says something like "Text encoding." Most passable text editors will have an option like this.

Heine’s picture

I've removed offtopic comments from this issue and created a FAQ page. If you have trouble with CSS and require support, post a new forum topic. Only post here to comment on the pending patch.

@Ashford; regarding "nothing changes"; are you sure you do experience the problem described in this issue, not some other problem?

Ashford’s picture

"@Ashford; regarding "nothing changes"; are you sure you do experience the problem described in this issue, not some other problem?"

Sorry for the delay in replying. I have been out of town and unplugged.

Before leaving town I put the site back to the saved backup of Drupal 6.17. It will be a couple of weeks before I have time to try the upgrade and the patch again. I am a volunteer webmaster for a nonprofit group, so I only get to work on the web site as time permits. I will report back as soon as possible.

12/7/2010 update

We are moving our site to another web host. I have a test site running now. I did figure out how to convert the files using my editor, HTML-Kit.

bgm’s picture

I had this bug in Drupal 6.16 and applying #25 fixed my problem. (thanks!)

Anybody’s picture

Heavy bug which cost me a lot of time to fix.

I just removed the UTF-8 signs (especially German ä,ü,ö,ß) and now everything works fine again.

When will the problem be solved in D6?

dsayswhat’s picture

#25 fixed this for me as well on Drupal 6.19.

fonant’s picture

Sadly neither the D6 patch, nor trying to convert ASCII css files to UTF-8 (they have no multi-byte characters so both are the same) worked for me. Am running with CSS optimisation off for now.

Heine’s picture

@Fonant, then you likely did not encounter the bug here, but another issue with CSS aggregation.

momper’s picture

puh - hours of research -> you should warn, warn, warn at a prominent place - this is near to a bug and typical drupal time waste ...

dddave’s picture

Whiny responses like yours don't help nobody. Did you use the patch? Did it help? See #48!

yurtboy’s picture

had this same issue on a 6.14 and 6.19 site.
I changed it from fast/cgi to mod_php and the issues went away.
Not sure if this will help anyone.

Gábor Hojtsy’s picture

Status:Reviewed & tested by the community» Fixed

Thanks, committed. This will be in the upcoming Drupal 6.20 release.

Status:Fixed» Closed (fixed)

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

gbernier’s picture

Hi All,

We are dealing with this issue on a 6.22 site, when we turned on CSS compression the sites all die where the CSS is there but none of the browsers are able to read it in. Was this fix actually rolled into 6.20?

Gene Bernier

introfini’s picture

CSS is there but none of the browsers are able to read it

this is a different issue.

Check if the CSS file is really created on the disk, you can be having permissions issues.

masher’s picture

I found a similar problem was caused by a un-closed comment at the bottom of a CSS file, causing everthing below it in the aggregated file to be ignored.

Heine’s picture

I'm closing this issue as it has been fixed.

A problem is not 'similar' just because it has CSS in the title.