Performance: When enable optimization for css and javascript ... site goes down instant!

You don't describe the symptom or error you get when it goes offline, but most likely (given the addition of theme developer triggers it) it's the normal old out-of-memory FAQ.
What's your php memory?

Do you mean to say your site goes into maintenance mode if you turn on js and css optimisation? Or are you just getting a blank screen?

- Arie

Looks like ro_x_taz won't be posting any feedback so I'm setting this to fixed.

Feel free to reopen if you think that is wrong.

- Arie

I have same problem. Drupal replies zero sized page using Zen starterkit ONLY if I optimize the CSS files, NOT the JS files.
I've tried to increase PHP memory to 512M but it didn't work..
Still can't find out why..

I trace the error in my Drupal 6.10, then stop in these codes :

common.inc line 1967, function drupal_load_stylesheet
<?php

    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.
        [\n\r]                        # Remove line breaks.
        >x', '\1', $contents);
    }

?>

It looks like the error comes from preg_replace function. I changed these codes to :

Adds double slash in line 1971
<?php

    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.
        [\n\r]                        # Remove line breaks.
        >x', '\1', $contents);
    }

?>

And everything works fine.. But, the CSS files don't optimized perfectly as comments are not removed..

I can't reproduce this behavior. Using Drupal 6.10 and Zen Starterkit 6.x-1.0 things are working fine using CSS compression on or off.

What kind of error do you see in the webserver's log? And have you tried the steps described here http://drupal.org/node/158043 ?

- Arie

I duplicate the error on wamp localhost with Drupal 6, but I have a massive amount of modules installed also, using Zen theme. When optimizing CSS is set to true then site is dead. Followed the method above and resolved the issue.

I was led to this error by way of using panels not displaying style in IE. There was a fix to simply make 'optimize CSS' as true. When selecting this it produced the error.

Oddly enough I'm getting a similar issue, except only for CSS Optimization, and not JS Optimization.

I've copied a production site to my local environment to do some debugging. I've cleared both the site and my browser cache, as well as the cache* tables inside the database.

I'm currently using two seperate themes for the front-end and the back-end. For some reason when I access the front-end, I either receive a "Connection Interrupted" message, or the page tries to navigate to www.localhost.com/*.
Nothing shows up in the error logs (including server logs).

If I change the front-end theme to Garland, everything works fine - so it's to do with my theme. However, the Production site is working with CSS Optimization enabled.

The fix above involving preg_replace works for me as well, but I'm not sure what caused this issue in the first place (given that I should be working with a mirror of Production locally, and CSS Optimization is working on Production).

Oddly enough, I never found in all the posts on css opimization issues a suggestion to run all css files through http://jigsaw.w3.org/css-validator/ I had a problem similar to many of the posts on the topic "css optimization breaks the theme" and tracked it down to a misplaced brace in one of the style sheets.

Hope this helps someone with a css optimization issue.

My solution was the same as comment #12. The error was in one of my Zen css files.

Here's the line you might want to check. I used Zen to create my own theme, so I had copied layout.css and renamed it to my_layout.css. Look for these lines...

/* Alternatively, the skip-to-nav link can be completely hidden until a user tabs
     to the link. Un-comment the following CSS to use this technique. */

----------- More lines - Keep scrolling down ----

  #skip-to-nav a:active, #skip-to-nav a:focus
  {
    position: static;
    width: auto;
    height: auto;
  }

*/

I had removed the comment line at the top and left the comment line at the bottom of that section. Check that line in case you did the same thing.

Ashford

I think the problem is when you have css aggregation enabled and then you change the default theme - for me that crashes apache on my local webserver.

On the other hand if I turn off the css aggregation, changing the default theme succeeds without problem.

(yes, I have a ton of other modules enabled too.)

I have this same problem using Drupal 6.13, Zen 6.x-1.0. My remote server is fine with CSS enabled. Using XAMP locally on two different machines runs great, but as soon as CSS Optimization is turned on, the site homepage returns a "connection reset" error message. Admin works fine with CSS Optimize turned on. Changing the site theme to Minelli or the Zen starter kit, and CSS Optimize then works fine. (My theme is based on Zen StarterKit.) I have searched and replaced every instance of single quotes in comments to no avail. Also, my homepage is valid CSS according to FireFox web developer.

Anyone have any tips on how to find out what the problem is?

Thanks!

I'm having the same issue, also using a Zen subtheme. I took out all apostrophes in the comments, checked for parsing errors using W3C Validator, etc. and my site still crashed when I turned on CSS Optimizer. The Javascript Optimizer works fine, it's only the CSS that does it (says "Connection Reset", not the Whitescreen of Death.)

I tried the suggestion in comment #7 and it seems to have worked, now it only loads 4 stylesheets (down from 20-something) -- thanks!

I was having the same exact problem.

I'm using Zen as well.

After noticing WYSIWYG + TinyMCE wouldn't display at all in IE6, I turned on CSS optimization and blammm... instant Apache crash.

Apache error.log:

[Mon Aug 24 09:37:49 2009] [notice] Parent: child process exited with status 128 -- Restarting.

One tip-off was that I have the admin module installed and I could get to any admin page, however the minute I'd hit anywhere else on the site... crash!

I'm guessing PHP might have a bug in "preg_replace". I followed comment #7 and commented out the line in common.inc and everything started working fine.

Thanks
-- Jason

Can confirm #7 worked for me, under Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9

I have the same problem, however if i make changes from #7 wont this be altering core?

If this is a bug for core wouldn't this be better to be added for update?

Edit: Well no, just experiencing the same issue, what I was suggesting is wrong.

While option #7 is a small edit if I update core and it over writes this file on the next security update it would soon come back, anyway if it was the cause why hasn't it come up on any of the other sites I have created over the past year. Does anyone know if this was an alteration for files in 6.13.

I am happy to try anything see if it makes any difference but before i start pulling apart core on my site I think I would like to have a better understanding of what the issue is.

Has anyone try to remove comments from Zen's CSS files? After I remove comments from Zen's CSS files, the WSOD never exists, even if using the original common.inc file.

Is this related to #543892: Win XAMPP 1.7.2 Regex PHP Bug - Optimize css & long css comments fails?

http://drupal.org/node/543892#comment-2069668

After almost 5 hours of debugging I can across this post... I confirm that the fix at #7 works

This is a serious bug and "normal" users will be left with a dead site I'm afraid.

The problem is not fixed in D6.14 so we still need to hack

If the maintainer needs more info I will be happy to give a case where its reproducible.

This is a showstopper since I do not enable css optimization out for performance reason but to get my site working under IE.

Maybe you know that IE only accepts 30 CSS files (you can run in this issue if you have a lot of modules) so I had no choice but to turn on this feature in production.

Confirmed, #7 works and from reading the thread and comparing it to my site, it suspect that it is to do with large comments in CSS files.

Confirmed fix in #7

A better fix that keeps the comment filtering functionality is in this thread: #444228: Optimize CSS option causes php cgi to segfault in pcre function "match".

D6 version of the patch is below. This is rolled against 6.x-dev.

Keeping the patch name in line with the original comment number on the other thread.

Update

See the linked issue above for the latest D6 patch.

same problem, the following commented line in style.css makes CSS compression fail and get naked HTML:

/* @import "css/screen.css"; */

patch at #7 does not help here.

The theme info file is probably a better way of including stylesheets, still adding my 2 cents to the saga ;)

@marco, yours may be a different issue: #544568: CSS aggregation attempts to process @import in comment

But, for the original issue, turns out they're actively providing D6 patches in #444228: Optimize CSS option causes php cgi to segfault in pcre function "match", so marking this as a duplicate.

It would probably help get the fix committed if folks would apply that fix instead and test the patches.

THIS WORKS FOR ME, 100% TNX
(but whats still the right solution?)

@mattez:

The correct solution is here #444228: Optimize CSS option causes php cgi to segfault in pcre function "match". The solution in that thread is being committed to core.

@gantenx

I can blow you kisses right now. Been working on my site for over a week and while doing final checks before deploying i decide to optimise css and it crashes. You are a lifesaver.

Gracias for the link!

Marking this as duplicate of #444228: Optimize CSS option causes php cgi to segfault in pcre function "match"

Comment #7 works.

I'm on local development using WAMP server on Windows 7.
PHP memory is 128MB
drupal 6.15
zen_ninesixty theme, a sub-theme of Zen

This is a duplicate of #444228: Optimize CSS option causes php cgi to segfault in pcre function "match". Please test the patches in that thread.

#7 works for my Drupal crash on turning on CSS optimization too.
I am using Drupal 6.16 and Zen 6.x-1.1 with CTI Flex 6.x-1.1 on Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9 (XAMPP on Windows Server 2008).

@kentr
Do you suggest applying the patch from February 20 mentioned here http://drupal.org/node/444228#comment-2625826 ?
Can I apply the patch to Drupal 6.16 or do I have to get the a particular head version from CVS?
I am upgrading the version number on this thread because I encountered this bug in Drupal 6.16.

I found out that, the CSS optimization crash bug on our Drupal 6.16 site is specific to what LAMP/WAMP setup we are using.

It does not crash on the following Linux setup provided by site5.com:
Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a Phusion_Passenger/2.2.11 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

It does crash on the following Windows 2008 Server plus XAMPP setup:
Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9

I wonder if the CSS optimization bug may be a symptom for a deeper problem.

@wgrunberg

I'm not sure which patch is current. My suggestion is more intended to direct all attention to that other issue.

I created blueprint sub theme and apache always crashed in IE. Because I copied and pasted the page.tpl.php from blueprint i didn't realise css file for IE did not exist yet in my sub theme. I created the css in my sub theme and fixed the path to css file in conditional comment and no more apache crash in ie.. hope this helps someone..

This bug persists in Drupal 6.17 in a XAMPP on Windows 2008 Server environment. I can't reproduce the crash on LAMP setups or on Windows XP or Windows 7. Thankfully the #7 hack still works.

I experienced a derivative of this. I found my site worked fine with CSS Optimize turned on, but one page was a complete mess. Again, commenting the optimizations (described in #7) made it work. It turns out it was cause by a trailing comment at the end of one .css file:

.node {
display: block;
} /*

That opening comment /* broke the optimizations, which is understandable because it's clearly not valid CSS. It was difficult to debug and I couldn't have done it without this thread, so I'm posting this comment in the hope that if you've found a similar problem, you'll be able to get to the (trivial) resolution quicker than I did.