This is more of a question to help fix a problem in CSSTidy. Not something I've encountered personally, let alone with your module.

There is a fix for CSS Gzip that move it's preprocess function after our modules.

Don't we also need a fix for Boost since it also Gzips the CSS files? Or am I missing something, here?

Comments

jcarnett’s picture

If Boost processes the CSS the same way CSS GZip does, then possibly. I'll have to look and see what it's doing.

philbar’s picture

It the same maintainer, so I'm assuming they both work the same way. But I could be wrong, Boost is obviously much more complex so it could process things differently.

philbar’s picture

I'm investigating and will let you know what I come up with.

Here is the boost issue I created: #875964: Compatibility Issue: Processing Gzip CSS Last

philbar’s picture

I did a comparison of hook_theme_registry_alter() for CSSTidy, Parallel, and Data URI Sprites.

See it here: http://drupal.org/node/829222#comment-3363370

Parallel and Data URI Sprites don't have the following bit of code, but are (as far as I know) compatible with Boost and CSS Gzip.

    // Move css_gzip's preprocess function after ours.
    if ($key = array_search('css_gzip_preprocess_page', $theme_registry['page']['preprocess functions'])) {
      unset($theme_registry['page']['preprocess functions'][$key]);
      $theme_registry['page']['preprocess functions'][] = 'css_gzip_preprocess_page';

Any thoughts?

jcarnett’s picture

CSS Gzip collects and creates the compressed CSS when template_preprocess_page() is run. Because of that, any module that modifies, adds, moves, etc CSS files must do so before CSS GZip gets to that hook in order to be compatible. Making any changes to the CSS after CSS Gzip runs will result in strange behavior. Once CSS Gzip compresses the CSS, that will be the version sent to the browser because the rewrite rules in the .htaccess will see that the gzipped version exists and send that instead of the original version, even if you modified the original version after CSS Gzip did its thing.

Parallel is compatible with CSS Gzip because it modifies the page output, not the actual CSS files.

Data URI Sprites is not compatible with CSS Gzip. CSS Gzip's template_preprocess_page() runs before Data URI Sprites's, effectively freezing the original CSS at that point. When Data URI Sprites's template_preprocess_page() runs, it modifies the original CSS (to no effect) and adds two more CSS files (one with the image data and one for mhtml). The end result is that the gzipped version of the original CSS is sent to the browser, and the two extra files are sent uncompressed (at least not by CSS Gzip).

I hope that makes sense! I still haven't looked at Boost. I'll try to do that soon.

jcarnett’s picture

Status: Active » Fixed

Boost uses output buffering to capture the full page output from which it parses the <link> tags to get the CSS files. Because of that, CSS Embedded Images, CSS Tidy, Data URI Sprites, etc. don't need to do anything special to work with it.

Boost does do one odd thing when parsing file names though that prevents it from caching/gzipping some CSS files with multiple periods in the name, but it's not a major issue for any of these modules. It could be a bug or could be intentional, but I'll probably end up changing my file names from ".emimage.css" to "_emimage.css" to try and avoid it though.

Status: Fixed » Closed (fixed)

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

joelstein’s picture

FYI... I was having problems with Boost and CSS Embedded Images for exactly the reason mentioned in #6. Your solution worked (changing ".emimage.css" to "_emimage.css"), but a better solution is to fix Boost's stripping of the file extension to support filenames with multiple periods. A patch has been submitted to Boost to fix this: #940554: CSS files with multiple periods (.) in the filename.