WP Super Cache version 0.9 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.

Update – if your blog is installed in a sub directory instead of at the root of your server, the .htaccess file might be wrong. Download and install the development version which corrects this. You’ll have to edit the .htaccess file (anyone want to volunteer to write an auto-upgrader?) and remove the rules between the lines # BEGIN WPSuperCache and # END WPSuperCache. Delete those lines too and visit your admin page. The plugin should do it’s stuff and spit out correct mod_rewrite rules for you. The dev version also has a few other bug fixes so if you’re adventurous have fun upgrading!
There’s no need to touch wp-content/cache/.htaccess

Are we nearing version 1? Possibly. In this release a number of bugs have been fixed and the following new features added:

1. Mobile user agents are detected and a different cache page created for them. If you use a plugin that displays a different theme to these devices it will hopefully work now. The plugin changes to “half-on” mode because the detection is done by PHP. Thanks to Alex King‘s WordPress Mobile Edition plugin for the detection code.
2. The number of cache files will be more than halved on a normal site with plenty of anonymous visitors. This should be a huge win for WordPress MU sites and very busy blogs.
3. The last and next garbage collection times are displayed on the admin page now.
4. In previous versions the newly generated page was delivered uncompressed to the first visitor even if the browser supported compression. I’ve fixed this but I’m not 100% certain it will work for everyone so it’s disabled by default. Edit wp-content/wp-cache-config.php and add “$wp_cache_gzip_first = 1;” to enable this. It’s enabled here.
5. If expiry time is longer than 30 minutes, garbage collection will be done every 10 minutes, else it’ll be done 10 seconds after the expiry time.

Unfortunately wp-content/advanced-cache.php will have to be updated again and it’s not as simple as copying the file from the plugin directory. Full instructions are printed on the admin page and it should auto update in most cases.

PS. Test your upgraded blog on Is my blog working, a project by fellow Automattican Alex Shiels.
Here’s the page for this site. 102ms page generation time is rather fast!

WP Super Cache version 0.8.9 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.

This version fixes a number of bugs and adds two new features, but in case you run into problems upgrading, make sure you delete wp-content/advanced-cache.php before copying plugins/wp-super-cache/advanced-cache.php over it. Go on, read that again. Delete that file. Jonathan Dingman didn’t and when he copied the file over the symlink he overwrote wp-super-cache/wp-cache-phase1.php. His site went belly up and he started screaming for my head!!! Err no, he appeared on #wordpress asking why it didn’t work. Thanks Jonathan for working through the problem with me. My fault for not making the instructions clearer!

If this happens to you, take a deep breath and unzip the plugin again in the plugins folder and delete wp-content/advanced-cache.php

Anyway, the new features are:

1. Cache rebuild. Serve a static cache file to anonymous users while that file is being generated.
2. Disable the large global lock that makes every access to the cache atomic.

Besides those, I got rid of the symlinked file in wp-content/, and the plugin now copies a file called “advanced-cache.php” from the plugin directory to simplify things. Especially on operating systems where symlink isn’t available. Yes, that’s Windows.

If your site is horrendously busy and you get a ton of comments every day and you’re too broke to buy a new server, then the cache rebuild feature will help you a lot. You should see the load on your server go way down if you enable this. Anonymous users who visit a page where a comment has just been left will be served a static cache file from the supercache instead of all the requests trying to generate a brand new page. The page served to them might be a few seconds out of date but that trade off is worth it.
Here’s the original thread that inspired the idea. Thanks Tigertech for writing the patch and for sharing the performance graphs. Check out the load on his server, before and after the rebuild function was switch on:

If you’ve had problems with deleting the cache on your blog it *might* be because of file locks. Some hosts just have problems with them. The file locking in the plugin is very coarse. When the plugin wants to do any sort of write operation it grabs a lock, does the writes (which could include clearing expired files, or creating wp-cache and supercache cache files), and then releases the lock.
Any other process running the plugin that tries that won’t get a lock: new cache files won’t be created, and cache files won’t be cleared.
It isn’t a huge problem that the lock is so coarse because the writes don’t take very long (the lock is enabled after the page is generated), but some very busy sites take quite a while to clear their cache files.
On the downside, disabling the file lock won’t stop multiple cached files being generated simultaneously (great), but it also won’t stop multiple “clear cache” attempts either (boo!)
From what I recall of looking at the other cache plugins for WordPress, most of them don’t have any file locking and seem to do just fine.

I almost forgot! There is also a new debug mode. Edit wp-content/wp-cache-config.php and look for “$wp_cache_debug” and follow the instructions. It will send you a few emails when things don’t go right and may help track down any problems.

As a final note, I would like to sincerely thank Robert Wolf who spruced up the admin page and gave it a nice lick of paint and Michael Torbert for helping me debug the plugin a while back.

WP Super Cache version 0.8.7 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.

This release addresses some issues large or busy sites had with deleting expired cache files. Some sites generated so many cache files that there were two many files generated, even when those files were cleared out every hour. To fix that I limited the recursive function that deletes the files to 100 deletions at a time. That function is called until all the cache files are deleted (or strictly speaking, no files are deleted. That’s how the expired file cleanup works).
It’s also possible to set the garbage collection interval to 10 minutes now which will also help.

WP Super Cache version 0.8.4 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.

This is a minor release but was prompted by White Shadow. He released a plugin that cleans up expired cache files on a periodic basis instead of after X number of hits. Great minds think alike, (or fools seldom differ) because I had the same idea a few weeks ago and had the code running on this blog for that time without any problems.

The garbage collection system should have operated this way in the first place, but at least now it’s easier to configure.

WP Super Cache version 0.8.3 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.

Double Caching

This releases fixes a long standing compression bug. In older versions of the plugin, the cached page was compressed twice. Once to display to the current visitor, and once again for the cached files stored on the server. This has now been fixed and there’s a noticeable speed increase for anonymous visitors. Unfortunately as a side effect, it’s not possible to display the “super cache gz” html comment now. To verify that html pages are being served from the supercache directory you’ll have to add an error_log() somewhere and check that visits aren’t logged.
The plugin now uses fopen() instead of gzopen() which according to a comment on the gzopen() manual page is unreliable under high load.

IE7 Fixes

Apparently IE7 has problems when gzipped files are served as “x-gzip” files, under certain circumstances. This is an obscure bug but this has been fixed. If you’re upgrading, either remove wp-content/cache/.htaccess and visit the admin page and that file will be regenerated, or edit that file and change “x-gzip” to “gzip”.

A number of smaller bugs were also fixed. Check the changelog for further info.

WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.

If you’re not interested in the changes, simply grab the latest version of the plugin and copy the files into your plugin folder. It’ll work, but if you’re upgrading, you should read on.

Major changes in this release:

1. Generate a semaphore id based on hostname and cache path to avoid problems on shared hosts, props Tigertech.
2. If you run WordPress from a different directory to where it’s installed, supercached files weren’t deleted when a post was made or updated. That is now fixed. Thanks Viper007Bond for all your help on that.
3. Paged archives, category pages, and tag pages are now cleared when a post is edited or comment approved. This replicates what WP Cache did all along so you should hopefully see supercached static files updating more often.
4. If your .htaccess is read-only, the mod_rewrite rules are displayed on the admin page. Thanks Matt for the patch.
5. Updated mod_rewrite rules won’t serve static html files if there’s a “=” in the url. Should catch all sorts of problems with plugins and attachments. You’ll have to manually edit your root .htaccess to match the new rules.
6. Set cache control and expiry headers of supercached files. They are cached for 5 minutes, but with a “must-revalidate” header. Delete wp-content/cache/.htaccess for the new rules to be updated.
7. Check for WordPress MU because it can’t update the .htaccess file.
8. Write supercache html to temporary files and rename. The old way opened the correct file for writing, did some work and wrote the file. In the fraction of a second it took to write the file, someone might request it and get an incomplete page.
9. The Supercache expiry time has been removed. There can be only one.

Edit: 0.8.1 has just been released. This addresses the following:

• The “forbidden files” problems some users had is fixed.
• Supercache files were being removed needlessly when a moderated comment was made.
• I added a “Clear cached files when post is edited” checkbox.
• I added a “Delete Cache” link next to the Dashboard link on the dashboard.
• Tigertech found that when a file is renamed and the new filename is already used, the old remains.
• Updated readme.txt.

WordPress.org user, “definitelynot” discovered a bug in the WordPress plugin, WP Super Cache that could expose blogs to duplicate content penalties. Unfortunately this affects every blog that uses the plugin in “ON” or full “Super Cache” mode, and has URLs that end with the “/” (forward slash) character. If the plugin is on “half on” mode, you’ll be fine.

The problem is that an anonymous user might visit a legitimate URL, ending with a slash, the plugin then creates a static file out of that page, which is then used when people visit the same URL. Unfortunately if someone links to that URL without the ending slash, a visiting browser or search engine bot won’t be redirected to the proper URL, they’ll be served the static html file.

For example:

1. John visits the URL /2007/05/23/why-the-nurses-cant-go-on-strike/ on my site. WP Super Cache creates a html file of that page.
2. In his enthusiasm for that post, John publishes a post about those zany doctors, but he forgets the ending “/”.
3. Googlebot, seeing fresh content on John’s site, crawls it and sees the link, visits my site eventually and wonders why it’s seeing the exact same page at two different URLs.

To be fair, Google is pretty good at figuring out where duplicate content is supposed to go but it’s better to avoid the issue completely. It also only matters if there are links to your site without the ending slash. The most common will probably be to your homepage as it’s likely internal URLs will be copy/pasted.

How to Fix
You should update to version 0.7 of the plugin which checks if your blog is affected by this problem. It also has instructions for updating the mod_rewrite rules in your .htaccess. It’s fairly easy to fix. Thank you “andylav” for the mod rewrite magic!

1. Edit the .htaccess in the root of your WordPress install.
2. You’ll see two groups of rules that look like this:
   

   RewriteCond %{REQUEST_METHOD} !=POST
   RewriteCond %{QUERY_STRING} !.*s=.*
   RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
   RewriteCond %{QUERY_STRING} !.*attachment_id=.*
   RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
   RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
   RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
   RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]
   
   RewriteCond %{REQUEST_METHOD} !=POST
   RewriteCond %{QUERY_STRING} !.*s=.*
   RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
   RewriteCond %{QUERY_STRING} !.*attachment_id=.*
   RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
   RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
   RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
   

3. You need to add the following 2 rules above each block of “RewriteCond” lines:
   

   RewriteCond %{REQUEST_URI} !^.*[^/]$
   RewriteCond %{REQUEST_URI} !^.*//.*$
   

4. The rules should eventually look like this:
   

   RewriteCond %{REQUEST_URI} !^.*[^/]$
   RewriteCond %{REQUEST_URI} !^.*//.*$
   RewriteCond %{REQUEST_METHOD} !=POST
   RewriteCond %{QUERY_STRING} !.*s=.*
   RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
   RewriteCond %{QUERY_STRING} !.*attachment_id=.*
   RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
   RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
   RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
   RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]
   
   RewriteCond %{REQUEST_URI} !^.*[^/]$
   RewriteCond %{REQUEST_URI} !^.*//.*$
   RewriteCond %{REQUEST_METHOD} !=POST
   RewriteCond %{QUERY_STRING} !.*s=.*
   RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
   RewriteCond %{QUERY_STRING} !.*attachment_id=.*
   RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
   RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
   RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
   

5. Or you could just delete those rules and let the plugin regenerate them for you again.

PS. Thanks also to Lloyd for noticing the “enable the plugin” link was pointing at the wrong URL, and to Ryan who spotted a minor problem with the admin page and was kind enough to send me a Tweet about it.
PPS. I’ve just tagged 0.7.1 to fix some problems with the updating of the .htaccess, mainly for new users. If 0.7 of the plugin works for you, there’s no need to upgrade!