Closed (fixed)
Project:
Boost
Version:
6.x-1.0-rc3
Component:
Core compatibility
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Aug 2009 at 22:02 UTC
Updated:
16 Sep 2009 at 19:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
mikeytown2 commentedgoing to mark this a dup of #543280: serve CSS and JS to logged in users. Please change if this is not the case.
Comment #2
neomenlo commentedActually it's not the same thing.
I had a problem getting boost to serve compressed CSS when the CSS was aggregated together by Drupal.
This is a bug because the javascript compresses even when it is aggregated by drupal.
It has nothing to do with being logged in or not.
The other bug is an improvement. Boost by design does not serve compressed css/js to logged in users, even though there shouldn't be a problem with it. That is because the rules for serving it are grouped in with the rules for serving static pages, which cannot be served to logged in users.
Comment #3
mikeytown2 commentedCan you check to see if it is both css files or only one of the aggregated ones. You have the media="all" one and the media="screen" one. Check both dir's gz and normal.
Comment #4
mikeytown2 commentedComment #5
chadd commentedi'm running into the same (i think) problem.
i have drupal's 'optimize css' enabled, and boost's 'cache css' enabled.
according to YSlow, the non-aggregated css files are never compressed.
in my case, it is 2 theme specific css files (/sites/all/themes/mytheme/assets/style/*) and the views module views.css
it seems that the drupal aggregated .css is being compressed, or at least they aren't showing up as "these should be compressed" in the YSlow report.
i've even tried adding the css gzip module (http://drupal.org/project/css_gzip) to the mix, but that seemed to have no effect.
Comment #6
mikeytown2 commented@chadd
Are the css files being stored inside the cache dir?
Comment #7
chadd commentedyes, i could find all the files in the cache dir, both normal and gz dirs
Comment #8
mikeytown2 commented@chadd
Can you give me one of the file names, full path from webroot and post the boost section of your htaccess file.
Comment #9
chadd commentedthe files that aren't being compressed (according to YSlow):
and my .htaccess:
Comment #10
mikeytown2 commentedTry this, it's for the latest dev; it also has some of the beginning of this thread: #546850: Next round of .htaccess changes. Getting these "perfect" is the goal..
The important part of this is the stuff inside the for loop and the code above it.
Comment #11
mikeytown2 commentedHere's a better one
Comment #12
mikeytown2 commentedcommitted
Comment #13
chadd commentedi just updated to the latest dev 6.x-1.x-dev (2009-Aug-31) and added the boosted1.txt from that release to my .htaccess and the problem seems to still be there...
in fact, now YSlow is reporting that the aggregated css is not being compressed either.
the files are still all being created (both gz and normal) just not being served (at least according to YSlow...)
Comment #14
mikeytown2 commentedgrab the htaccess rules from the performace/boost page, as these are generated to fit your setup. Let me know if that does it for you.
Comment #15
mikeytown2 commentedchanges to the htaccess1/2.txt files
Comment #16
mikeytown2 commentedcommitted, please change back to active if it still doesn't work.
Comment #17
chadd commentedNow it looks like none of the css is being served via gz, and it also looks like now the page itself isn't being served via gz.
it's all there in the gz dir, but not being served (according to yslow)
Boost 6.x-1.0-rc3 using the .htaccess from rules from the performace/boost page
Comment #18
mikeytown2 commented@chadd
Any chance I could get a login to look around your site to try and see what is wrong? use my contact form.
http://drupal.org/user/282446/contact
Comment #19
mikeytown2 commentedYour server is not serving any gzip content other then the jsmin.js.gz file from the http://drupal.org/project/javascript_aggregator module. For some reason it's completely ignoring the gzip part of the boost rules. Luckily RC3 has the fix, I just tested it on your server! Enable 'Do an iframe javascript cookie test for gzip' on the performance/boost page. I tested this by setting the boost-gzip cookie. As for why javascript_aggregator is working and boost isn't, is very strange since I helped get gzip working on that module. It might have to do with firewall issues; here's the article that inspired me to add this functionality.
http://actionable-stats.com/website-performance-activate-gzip
Just for kicks can I see your root htaccess file and the one located in files/js/
Comment #20
chadd commentedthe odd thing is that our production server, running Boost 6.x-1.0-rc2, serves up all gz files without a problem except for the non-aggregated css mentioned above. or at least, the only files that YSlow complains about not being gz is the non aggregated css...
after enabling the 'iframe' check it looks like all the files get served via gz in the RC3.
does the iframe cookie test have any impact on load times or browser compatibility?
here's the files you requested:
root .htaccess
files/js/.htaccess
Comment #21
mikeytown2 commentedThe 'iframe' check is only injected on the front page, and only on the non-gzip version of that; and it uses a static html file to check, so the performance impact is minimal. It shouldn't effect browser compatibility, as browsers that don't understand gzip can't read the iframe, thus can't get a cookie set. If you have a blackberry then you can test this on a non gzip supported browser. Also means that if the user doesn't hit the front page then, they won't get that cookie set. It's set to last for 2 weeks.
What this output?
The only thing I can think of is the not (!)
Comment #22
chadd commentedupgrading to RC3(4) worked and now everything is being served via gz.
thanks much!
this module is a lifesaver.
Comment #23
mikeytown2 commented