dynamic css generation creating overhead

Now that you mention it, this does kind of make sense. I've recently found out that Drupal tells browsers NOT to cache the pages that it generates. This means that rather than caching CSS files like browsers usually would, they'll call them with EVERY page hit.

Good catch! I'll try and come up with a workaround for this.

I need to look at the code again, but I think that the reason that I created a dynamic "virtual" CSS file was so that we could inject variables into it. I'll have a look at it again though.

Ahh.. I see... You're sticking it all into the page html. Yeah that'll work too. But again, you've still got the effect of loading the code for the sIFR CSS files for each page load -- albeit that they're not actually separate files.

I think I'm going to look into creating a sIFR.css.php file that will load the Drupal variables. It will output its content directly so we should be able to control the browser caching stuff.

• Is there a 'force caching' method in Drupal we might use for this issue? If not, I think it would be best to (re-)write a static CSS file after each rule edit in /files/sifr, since sIFR settings and rules are only set up once.
• Please take different sites into account - a sifr.css[.php] would have to be named sifr.$sitename.css.

what if after adding/editing a rule we generate a static css file and store the path in the db. this would move all performance hits to the rule creation stage avoiding any drupal/browser caching issues.

Any thoughts?

Great idea. Though, I'm not sure that there is really much overhead in loading the CSS stuff. If I remember correctly, it's just loading variables using variable_get() and all of the variables are already cached and loaded with each page. So there really aren't any "extra" database hits.

I think the larger problem (and this is really another issue) is that the dynamically generated .css files aren't outputting the correct headers in order for the browser to cache them. This means that the browser asks for every sifr-related .css file on every page call. Not cool.

Actually... no... the CSS caching problem isn't a separate issue... it's *this* issue. :-)

Here's some clues:

Drupal header (for ALL pages) gets set here:
http://api.drupal.org/api/4.7/function/drupal_page_header
notice the "Expires:" header

PHP header function should be able to override pre-existing headers before they are sent to the browser:
http://us3.php.net/header
see also:
http://us3.php.net/manual/en/function.headers-sent.php

It seems like you should be able to set the expiration headers in the same place that sifr is outputting the header("Content-type: text/css"); and things should work. But I've done a little experimenting and haven't gotten it to work yet.

Good way of testing headers:
http://livehttpheaders.mozdev.org/

sounds good. thanks for pointing me in the right direction.

Another direction:

We could also write a CSS file to the 'files' directory. This might actually be the best solution because then Apache will take over and we won't have the problems we've been having.

It also *could* be interesting to experiment and see if we can get the sIFR module to download sIFR into the files directory itself!

We could be back to the same problems though, if Drupal's download method is set to "private", as everything from the files directory will get sent through Drupal before being sent to the user.

good call. i hadn't thought about the 'private' option for the files directory.

This issue is already fixed for 4.7 and 5.

Although $sitename is not taken into account in that fix I am closing this issue now. So using sifr in a multi-site setup won't work out. But let's wait until someone complains that and hopefully comes up with a patch already including a module update function...