I was pretty excited to see an update to WP-Cache. The first thing I noticed is that when I enabled the new super cache compression option, I started getting a file save as dialog instead of my pages. As of the current version of WP-Super-Cache, the readme.txt file states that if you get this, you need to disable the super cache compression option.
Not being satisfied with this answer, I’ve done a little digging and come up with the following solution.
To serve gzipped pages to a browser, you have to have the following HTTP headers in the response:
Content-Type: text/html
Content-Encoding: gzip
The problem is that the default content headers that my Apache server were sending for the file extension .gz were:
Content-Type: application/x-gzip
I didn’t want to override the default types for other sites or files I may host, so I created a Location element that applies to the wp-super-cache directory:
<Location /wp-content/cache/supercache/>
AddEncoding x-gzip .gz
AddType text/html .gz
</Location>
The .htaccess requirements are covered in the readme.txt file for the plugin but the options tab only shows you 1/2 of what you need. Your new .htaccess file should look like this:
<IfModule mod_rewrite.c>
RewriteEngine On
# this part handles browsers that accept gzip compression
RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz [L]
#this part handles browsers that don't accept gzip compression
RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html [L]
# the original rules must follow the supercache rules
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
There. All working. If it isn’t working for someone, let me know! I’ve tried recent versions of Safari, FireFox and Internet Explorer. You should be able to see the text “super cache gz” at the bottom of the source page if this is working correctly.
UPDATE: Donncha has integrated the headers into a .htaccess file inside the cache directory in the development version of the plugin. If you upgrade to that, you don’t need to make these changes and it appears to be working properly. Thanks Donncha!
Man, I was having exactly the same problem. Your fix is spot on! Thank you.
I actually came up with the same solution but with an extra .htaccess file in the cache folder before my initial release of the plugin, but at the time feeds were cached and the compressed feeds weren’t playing nicely with Feedburner.
That’s all changed now as feeds aren’t cached so I can fix it again. Thanks!
Location can’t be used in a .htaccess, so I’ll probably have to create that file in the cache folder again.
Oh yeah, did you disable the plugin? I don’t see the caching string at the end of this page, even before I left a comment.
I put the Location into vhosts.conf. It works if you have access to apache configuration files, but I’m not sure where you would put it otherwise…
Hey Donncha, I still have the plugin enabled. I get the gzipped response when I telnet to port 80 and create a request with Accept-Encoding: gzip as one of the headers. You might try a different browser and look at the source. That’s how I tested it mostly since when you’re logged in you don’t get the super cache pages.
Actually, now that you pointed it out, I double checked the contents of my super cache directory. I’ve noticed the index page and a few posts are cached (and have gz copies) but this post, and a number of others do not have a cached copy. I noticed that after I made these comments, the cached copy of the index page was regenerated (to show the correct comment count), but still, there is no updated cached copy for this post. I’m going to try deleting the cache, and seeing what gets regenerated.
Sure enough. After deleting the cache, the index page, meta pages (tags, categories) and a lot of older posts are getting put back into the cache. These latests two posts about wp-cache are not being stuck back in the cache though. I have no idea why this is. I’m on version 0.3.1 of WP-Super-Cache.
Just checking,
This goes in the .htaccess file right?
Unfortunately, you have to put it in your vhosts.conf (or httpd.conf depending on your setup) if you want to use the Location element. You can Add the AddEncoding and AddType headers to their own .htaccess file in the /wp-content/cache/supercache directory though. I haven’t actually tried this but it seems like it ought to work.
I found out why my last two posts weren’t being cached. They had wp- in the URL, which is a rejected URL string on the cache options. I changed the slug in the post to wp_ instead for that part and it fixed the problem.
It is sort of ironic to have a post about wp-super-cache not being cached isn’t it.
Update your plugin and change the “wp-” to “wp-.*.php”
It now uses preg_match instead to match strings 🙂
Did you mean update to a new plugin version? I still see 0.3.1 as the latest. If I change the wp- in the current version will it break?
Never mind Donncha, saw your post on the WordPress plugin page about the changes being in trunk.
I think the development version is right on! Thanks.
Super cache compression is working. Wp-cache is caching files and storing them in the cache directory. The only files being cached according to the listing is feeds and print files.
Anyone know why the other page loads are not being cached. There is no indicator at the bottom of the source file about wp-cache, just compression even when reloaded.
Thanks for the help
Thanks, did the same thing on my blog. Firefox figures out the page is HTML despite the gzip HTTP header, but Internet Explorer gets confused and prompts you to download the site. The .htaccess file in the cache directory fixes the headers.
Hi Dennis, I’m having some trouble buddy. I’m able to run Super-Cache properly (as long as GZip is not enabled) on IE6 and IE7; however, once it’s enabled, it asks me to download the page. I tried following your aforementioned code, but it results in the website not even loading on IE6/7. I pasted the “” code in my /cache/.htaccess folder and the “<IfModule mod_rewrite” code in my main .htaccess under my public_html folder. When I made these modifications, the site still works on Safari and Firefox, but not Internet Explorer. Let me know if I overlooked something.
Best I can recommend is using telnet to grab your web page and examine the exact headers that are being sent/received. Or you could try tcpdump or something. You’ll have to determine which header is missing or incorrect.
Hi! It does not work on Litespeed servers 🙁
I geuess the suspect is:
AddType text/html .gz
as the pages are rendered as garbage text under IE. Such a pitty, unless there is a solution.
Oh, it’s solved now. Litespeed compresses the files anyway.
Recently moved servers from StartLogic to HostGator. Having a problem with WP-Cache. I know how to set it up. I know about permissions. It just would not work on HostGator (even though others have it working).
Then I found SuperCache and decided to try it. Funny. SuperCache works for IE. And for FireFox- on my other machines, but not my Toshiba laptop. I just completely removed Firefox and reinstalled – same thing.
Any ideas?
Install FireBug (Plugin) and see what headers are being returned. You can use Telnet to debug the raw information returned too.
Pingback: WP Super Cache – The Ultimate WordPress Caching Plugin | All My Brain