CSS_GZip doesn't work with Pixture and other color-based themes. [#554146]

I have Pixture theme (http://drupal.org/project/pixture) and also the default Garland (with some color modifications). Both are color based theme, so unique CSS files are generated depending on user choices.

I have noticed that while CSS_GZip module will create gzip versions for some of the aggregated css files, it won't do it for all of the aggregated CSS files. So when I run YSlow it still shows that the aggregated CSS file is not gziped.

Please allow CSS_GZiping for the generated files by color based themes like Garland, Pixture, Wabi etc - because these are very popular and widely used themes.

Comment	File	Size	Author
#7	css_gzip-554146.patch	9.13 KB	mikeytown2
#6	css_gzip-554146.patch	9.43 KB	mikeytown2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mikeytown2 CreditAttribution: mikeytown2 commented 19 August 2009 at 22:10

Last time I checked, it worked with Garland; I will try to duplicate the bug using Pixture.

Comment #2

drupalina CreditAttribution: drupalina commented 19 August 2009 at 22:18

It works with Garland only if you leave it with its default blue colours. But things are different when you change those colours to Red or Yellow.

Use Pixture or Garland, but make sure to change the colours in your theme settings so that a new CSS aggregate file is created. And then you'll notice that not all CSS files are being GZipped.

Comment #3

mikeytown2 CreditAttribution: mikeytown2 commented 19 August 2009 at 23:48

Figured out the problem.
phptemplate_preprocess_page() is inside the garland theme. That calls http://api.drupal.org/api/function/_color_page_alter/6">_color_page_alter(). That function rebuilds the aggregated css file via $vars['styles'] = drupal_get_css($vars['css']);. Changing the module weight doesn't work, so I'm not sure what would be the best way to fix this... patching core is plan A (#101227: Gzip aggregated CSS and JS) OR plan B is to use the "nuclear" option via output buffering. If you gotta have this asap, boost could do this for all pages since it already uses an output buffer; open an issue over there and I will make it happen.

Comment #4

drupalina CreditAttribution: drupalina commented 20 August 2009 at 02:38

No, it's not a rush for me personally. I just thought that because these color-based themes are so popular with drupal users who just use it out of the box, it would be really nice to have CSS_Gzip to work for them too.
I'm not a big fan of patching the core (especially since I don't know how to patch), and I'm not techie-enough to understand your other proposals. But if you come up with some sort of working solution at some point in the future, I'll be sure to test it.

Comment #5

mikeytown2 CreditAttribution: mikeytown2 commented 20 August 2009 at 08:29

I could try ob_get_contents() and overwrite the page cache, kinda how beautify works. Call it in hook_exit. Get my css gzip code from boost. Make this an optional way of doing it; port it over to my parallel project as well since that uses the same "hook" as this. Need to copy whats in drupal_page_footer(). Clear the output buffer, do a print, then call page_set_cache(). This is what I call the "nuclear" option, and it should work without hacking core, but its massive overkill in terms of just wanting to get the css filename. Some of the above will be specific to parallel (all the caching stuff).