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:
- Cache rebuild. Serve a static cache file to anonymous users while that file is being generated.
- 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.