Tag Archives: wp-super-cache

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

Since the last release of the plugin a number of new features have been adding, bugs fixed, and documentation updated. For a taster, here are the changes from the readme.txt:

1. Fixed problem with blogs in folders.
2. Added cache file listing and delete links to admin page.
3. Added “Newest Cached Pages” listing in sidebox.
4. Made admin page translatable. (work in progress)
5. Added “How do I make certain parts of the page stay dynamic?” to FAQ.
6. Disable supercaching when GET parameters present instead of disabling all caching. Disable on POST (as normal) and preview.
7. Fixed problem with cron job and mutex filename.
8. Warn users they must enable mobile device support if rewrite rules detected. Better detection of when to warn that .htaccess rules must be updated (no need when rewrite rules not present)
9. Use the wordpress_test_cookie in the cache key.
10. Show correct number of cache files when compression off.
11. Fixed problem with PHP safe_mode detection.
12. Various bugfixes and documentation updates. See Changelog.txt
13. Advanced: added “late init” feature so that plugin activates on “init”. Set $wp_super_cache_late_init to true in config file to use.
14. Advanced: Added “wpsupercache_404” filter. Return true to cache 404 error pages.

If you’re upgrading and your blog is installed in a sub directory the mod_rewrite rules may not have been created correctly. You’ll know this because the timestamp on your cached pages will change on every load. If that happens, remove the Supercache rewrite rules and recreate them through the admin page.

You can list all the blog’s cache files now, ordered by generation time. From that listing you can delete individual files.

The debug function is very powerful. You can choose the level of logging. Level 1 logs errors and warnings of a serious nature. Level 5 logs them plus lots of normal functions. Here’s what level 5 logging looks like for one single request:

20:49:34 /was-the-janitor-really-in-the-fugitive/ No wp-cache file exists or user agent rejected.
20:49:35 /was-the-janitor-really-in-the-fugitive/ In WP Cache Phase 2
21:49:35 /was-the-janitor-really-in-the-fugitive/ Setting up WordPress actions
21:49:35 /was-the-janitor-really-in-the-fugitive/ Created output buffer
21:49:35 /was-the-janitor-really-in-the-fugitive/ supercache dir: /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/
21:49:35 /was-the-janitor-really-in-the-fugitive/ Output buffer callback
21:49:35 /was-the-janitor-really-in-the-fugitive/ supercache dir: /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/
21:49:35 /was-the-janitor-really-in-the-fugitive/ Anonymous user detected. Only creating Supercache file.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Gzipping buffer.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Writing non-gzipped buffer to supercache file.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Writing gzipped buffer to supercache file.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Renamed temp supercache file to /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/index.html
21:49:35 /was-the-janitor-really-in-the-fugitive/ Renamed temp supercache gz file to /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/index.html.gz
21:49:35 /was-the-janitor-really-in-the-fugitive/ Sending buffer to browser

That’s a lot of text. Keep an eye on the load on your server because logging that much data on a busy server will add extra load. Start by limiting the logging to your own IP and test with various browsers.
The error messages that are normally sent to the browser about “missing html tag”, “404 error” and “blank page” are now only shown if debugging is enabled. This will hopefully avoid problems with PHP scripts that generate Javascript.

This release adds a new “late init” feature. This is only useful in half-on mode however. This causes the plugin to create the “cache key” and display the cached page at the end of the “init” action, after all WordPress include files and plugins have been loaded. This is very useful if your application needs to interrogate the database to modify the cache key. Activate it by setting $wp_super_cache_late_init to true in the config file.

Lots to digest and new toys to try out. Hope you enjoy this new version of the plugin!

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

Major changes under the hood in this release, and many bugfixes:

• If your blog is installed in a folder then compare the mod_rewrite rules in your .htaccess with those on the admin page. I fixed a bug in how those are generated.
• Out goes the shutdown function the plugin relied on for years (going back to the days of wp-cache), and in comes plain old output buffering on it’s own.
• If you’ve had problems clearing the cache on your blog it could be because wp-cron isn’t firing. I’ve added checks for that. Joost helped me debug that and he blogged about it too. You’ll get a nice warning message if those checks fail.
• If after all that, your cache still doesn’t clear, add $wp_cache_shutdown_gc = 1; to wp-content/wp-cache-config.php to clear the cache at the end of pageload instead of by wp-cron. It will slow down page generation for a tiny number of your users though.
• The Last and Next garbage collection times are now in the timezone selected for your blog.
• Added an admin notice on the plugin page to warn that caching has to be enabled. A warning is shown below the plugin activation row too.
• If your site runs on a Windows server, I fixed a small problem with slashes and creating the config file.
• The plugin created empty supercache folders, but that’s fixed now.
• Bad Behaviour support seems to work nicely now!
• You can now relocate the supercache plugins folder. See $wp_cache_plugins_dir in wp-cache-config-sample.php.
• I added 2 new filters: wp_cache_served_cache_file in wp-cache-phase1.php (BB uses this) and wp_cache_file_contents in wp-cache-phase2.php where you can filter the contents of the newly created cache before it’s written out to a file.
• The readme.txt has been updated too warning about using NFS to store the cache folder, solving wp-cron problems, added the list of Apache modules required for expired pages to really expire in the browser cache.

I also added a donation link in the readme.txt and on the admin page. You can hide it with the click of a button but if you’re feeling generous, I’d appreciate a donation.
I don’t expect many donations, that’s how these things work, but if you tell me your site does 100,000 page views a day and you couldn’t live without caching I might be slightly annoyed if you come looking for free support.

PS. Looks like Bad Behavior support is broken because the docs on the BB site were a little misleading and I don’t use the plugin. Grab badbehaviour.php and copy into plugins/wp-super-cache/plugins/ overwriting the file of the same name in that folder.

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.