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:
- 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.
Discover more from Something Odd!
Subscribe to get the latest posts sent to your email.
A question for you. I have been using supercahe on a site which had this load. (It is a VPS)
Load 0.8 / 0.86 / 0.44 ( 1/5/15 minute load) and was all working great but then the ad agency wanted me to add a really simple tracking image so they can see whenever the homepage gets loaded for their stats programme.
BTW already have google analytics so we know what that is and can see all of the traffic sources.
Anyway they complained that the tracking image isn’t working. I suspect it is because of the caching.
GA uses JavaScript to embed the tracking code but the ad image is just a simple html type image. I’m wondering if there is a way to have that tracking image load AND still have the super caching on.
For a test of my theory I have turned off the caching over night to see if their readings improve but it would be faster all round if we can do both.
Warning! /home/****/public_html/ is writable. Please make it readonly after your page is generated as this is a security risk.
I have been getting this error message. I have ignored it now.