I recommend a few changes in the context of compression and etags that would have simplified my initial experience with W3 Total Cache.
1. Compatibility testing claims to check for “mod_deflate / mod_gzip” but the code in inc/lightbox/self_test.phtml checks only for mod_deflate and not mod_gzip. In fact, it appears none of the code in lib/W3/Plugin that generates the <IfModule>..</IfModule> code for the .htaccess file refers to mod_gzip, only mod_deflate. I’d remove all reference to mod_gzip (especially in the compatibility test) as misleading.
2. My hosting service is running SuExec on its servers, and in this setup PHP runs as CGI and not as an Apache module, so the function apache_get_modules() used in self_test.phtml to get the list of loaded modules does not work (so the compatibility testing saying modules are not detected is true but misleading). I just noticed that you allude to this in another thread.
3. My hosting service has mod_gzip installed, but does not have mod_deflate and claims mod_deflate cannot be installed. It would be nice if the <IfModule mod_deflate.c> section were followed by a <IfModule !mod_deflate.c> section that contained a nested <IfModule mod_gzip.c> section to do the compression with mod_gzip. (I understand that mod_gzip may now be deprecated.)
W3TC disables ETags by adding code of the form “<FilesMatch REGEXP> FileETag None </FilesMatch>” to the .htaccess file. The REGEXP matches file extensions like “.jpg”. But the matching is case senstive, so if the images are produced on a windows machine and get the extension “.JPG” then the match fails and ETags are generated. I recommend adding “/i” to the end of the REGEXP so that matching is done caselessly. (This issue does not arise elsewhere since, for example, AddType treats extensions as case-insensitive.)
Thanks, and good work.
- The topic ‘[Plugin: W3 Total Cache] Recommendations for gzip compression and etags’ is closed to new replies.