Posted by cbas@pandion.be on July 12, 2009 at 1:00pm
| Project: | Javascript Aggregator |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | derjochenmeyer |
| Status: | closed (fixed) |
Issue Summary
After installing and enabling the module I found that my browser (FF3.5+Firebug+PageSpeed) does not receive the JSmin+GZip version from the cache. Is this just me or is the module not working for anyone else either?
It seems the .htaccess file is set up for .js -> .gz files, but the code generates a cache of .jsmin.gz files so Apache won't find the GZip cache.
Also, the $footer output contains references to the .jsmin files which is just wrong as the .htaccess directives don't even look at that. In fact the .jsmin files should be removed as it's only an intermediate step and simply wastes disk space.
Fixed javascript_aggregator.module:
104-105;
if (!file_exists($aggregated_file .'.gz')) {
file_save_data(gzencode($contents, 9), $aggregated_file .'.gz', FILE_EXISTS_REPLACE);138: //$scripts = str_replace($aggregated_file, $jsmin_file, $scripts);
Comments
#1
Turned this into an actual patch against DRUPAL-6--1 in CVS. Patch attached. Needs testing.
#2
You are gzipping the aggregated file and sending the aggregated.js.gz, not the aggregated and minified file which is better. Anyway, it's a server configuration problem, see http://drupal.org/node/290280#comment-1392934
On localhost, I had this problem with the module (and that's why I came here), but on the production server, the module works fine.
#3
#0 All your patch does is to bypass the JSMin minification. That makes no sense.
Check the screenshot. After enabling javascript_aggregator AND (!) clearing the browser cache (!) YSlow hands out a B on "compress components with gzip"
The css file is the only one which is not gzipped.
#4
@#0:
Like #3 said, do some more testing, clear site & browser caches, refresh... Didn't work for me first time around either but finally it did.
From reading the GZip CSS issues, my understanding is that the non gzipped version has to remain for browsers that don't support gzip. .htaccess is supposed to test and only rewrite for browsers that support it.
RewriteRule ^(.*)\.js $1.js.gz [L,QSA]Looks to me like any
*.jsfile is supposed to rewrite to*.js.gz. That includesxxx.jsmin.js. According to the GZip CSS project, on some servers you have to put the rules in the main .htaccess rather than in a per-directory .htaccess. Maybe your server is one of those. Try placing the rewrite rules in your main .htaccess.Servers also handle rewrite rules differently (at least for me, who may very well be writing crappy rewrite rules). Could be that the rule just doesn't work for your server.
#5
I just ran into this issue, and for me it was due to running in an Apache environment using VirtualDocumentRoot. This requires that a RewriteBase be used, and the .htaccess file output by the module lacks one. In my case, the site needs a "RewriteBase /" in the root .htaccess, which translates to "RewriteBase /sites/default/files/js/" in the module's .htaccess. The following code achieves this:
<?phpif (!file_exists($htaccess)) {
$rewrite_base = '/'. file_directory_path() .'/js/';
$htaccess_contents = <<<EOT
<Files *.js.gz>
AddEncoding x-gzip .gz
ForceType text/javascript
</Files>
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase $rewrite_base
RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)\.js $1.js.gz [L,QSA]
</IfModule>
EOT;
file_save_data($htaccess_contents, $htaccess, FILE_EXISTS_REPLACE);
}
?>
Unfortunately, this isn't a general solution, since others will have different RewriteBase requirements. Any way to detect the appropriate one so this module can work generally without patching?
#6
I'm having a similar issue, which is preventing me from using an alternate domain for javascript files under Parallel. I'd love to see an option to not include an .htaccess file at all, like the CSS Gzip module has. Then we could use our own .htaccess, with rewrite rules to fit the situation.
#7
#5, thanks a lot for your problem's solution! It turn on Javascript Aggregator's Gzip function on my virtual hosting configuration.
#8
Solution in #5 solve my problem as well, using version 6.x-1.4, thanks JonBob. I also apply the solution to CSS Gzip module version 6.x-1.3 which has the same issue. Without the proper RewriteBase directive in .htaccess, the cache files are simply not found. I think it's better to let the user manually add the required rewrite rule in the root .htaccess and provide option to turn off .htaccess generation in path-to-files/js just like CSS Gzip do. The README file should be updated to reflect this issue.
#9
Re #5:
error.log:
[Mon May 31 16:38:57 2010] [alert] [client XXXXX] /var/www/drupal/sites/default/files/js/.htaccess: /var/www/drupal/sites/default/files/js/.htaccess:15: <?php> was not closed., referer: http://XXXXX#10
Can we work this into a patch. This seems to have no impact on regular configurations, right?
#11
#6: Optional .htaccess is possible now, see: #619870: Make .htaccess creation optional
#5: Can we use base_path() for a general solution? Attached patch implements this, please test.
#8: The README.txt got an update.
#12
committed patch to 6.x-1.x-dev
http://drupal.org/cvs?commit=481718
#13
Automatically closed -- issue fixed for 2 weeks with no activity.