WP Super Cache 0.9

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!



By Donncha

Donncha Ó Caoimh is a software developer at Automattic and WordPress plugin developer. He posts photos at In Photos and can also be found on Google+ and Twitter.

107 replies on “WP Super Cache 0.9”

NVM got that working, now i’ll just wait a day to see if it has any luck. Just letting you know I don’t use comments on my site, so it’s all 100 percent static. Just get;s 700k of page views a day . thanks for helping me out here.

Vahid – you’re welcome! 700k visitors? I’d really appreciate a link here from your site. I can only imagine how busy your server is!

Stephen – if you use a lot of plugins try disabling them and reloading your blog as you enable your plugins one-by-one. That’ll find any bottlenecks. Core WordPress is very efficient.

Which set of .htaccess rules do I use? Do I use the ones in the readme or the ones that it suggests I put in in the admin panel? The ones in the readme has three extra lines on the end:

`RewriteCond %{REQUEST_FILENAME} !-f`
`RewriteCond %{REQUEST_FILENAME} !-d`
`RewriteRule . /index.php [L]`

Hi Donncha,

It would really be appreciated if you could add the compatibility code for Bad Behavior to your own releases as I previously requested (and others have since concurred). The rapid development of WP Super Cache is much appreciated, but adding this compatibility code to every new release is becoming a bit of a chore. 🙂

Thanks again for all your work on this, Donncha. Though I can’t imagine mobile traffic being terribly high at most blogs yet, especially mine, I think it’s important to prepare for a time when mobile access to the Internet is pervasive and ubiquitous. Yours and Alex King’s work will go a long ways towards making sure WordPress stays out ahead of the crowd in this area.

Lee – eventually it’ll be included once I can come up with an elegant way of doing it.

Dave – ‘fraid not. It’s a PITA to code as it’s so low level and even now it doesn’t work properly for some some people.

Matthew – thank you. The mobile detection had to be one of the most requested features ever.

Randy – it’ll get you most of the way, but visit the admin page to complete installation (create the wp-content/advanced-cache.php)

Great plugin. But what does mean when it says “Your blog application probably doesn’t support browser caching.” Is there a WordPress setting I have to enable for this?

Hi. Really great work with this caching plugin Donncha!

Since the latest upgrade from version 0.8.9 to 0.9 we’re getting a lot of errors/warnings in our logs.

[27-Jan-2009 20:11:05] PHP Warning: unlink(/x/wp-content/cache/wp-cache-c9697e6033f0108d11066a1ba36a7189.html) [function.unlink]: No such file or directory in /x/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 305
[27-Jan-2009 20:11:05] PHP Warning: rename(/x/wp-content/cache/547696244497f5c498ddec1.41438234.tmp,/x/wp-content/cache/wp-cache-c9697e6033f0108d11066a1ba36a7189.html) [function.rename]: No such file or directory in /x/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 306

There is no such problem with version 0.8.9.
The error is generated using 0.9, by an anonymous user visiting the site (wp-cache), registered users (wp-supercache) aren’t producing this warning.

kaset – I think I found the error, download the plugin again in about 15 minutes and install and it should go away. I haven’t tagged version 0.9 yet which is why the zip file updates. It’s generally a bad idea to do this but I wanted to give it a day in case any minor bugs showed up.

Jon – AFAIR, WordPress sends a “nocache” header so your browser always requests the newest version of the page. I think that’s it.
Statically cached files are cached in your browser for a few minutes.

I’m noticing one change from 0.8.9 to 0.9 and it’s that if supercache is turned on and I browse as an anonymous user that the supercache file keeps being re-created each time I refresh a page. I can tell it’s being re-created as the timestamp at the bottom of the page keeps changing and the file in the file system changes too.

I’ve switched back and forth between versions, done clean installs, etc, and keep seeing the same problem. I’ve also grabbed the latest trunk version from SVN to pick up your fix for the warnings above but the problem remains.

If I switch to half-on mode, refresh the page as the anonymous user then turn supercache back on again, then from that point on all is well and the supercache file doesn’t get recreated with every subsequent refresh (the difference being that the old wp-cache version of the file has now been created). Hope that helps!

John – I visited your site and reloaded the front page and the timestamp stayed the same each time at 2009-01-27 21:05:49.

If I refreshed after a few minutes, even 2 minutes, the timestamp did change. Do you have a short expiry time? Have you verified the supercache files are being generated?

I do indeed have the mod_rewrite rules in my .htaccess and note that they’ve not changed since 0.8.9 (on which it works). Perhaps there’s something specific to my server that’s causing the problem if you’re not able to reproduce it yourself. Not to worry, half-on is good enough for me!

I’ve improved the way page generation time is calculated on, to discount the connection setup time (it measures the time from when the connection is established, to the time that the server started delivering data). is now showing about twice as fast, around 50ms or so.

Twice as many reasons to use WP Super Cache 🙂

Everything seems to be working okay but I just have a couple minor questions when you get the chance.

I auto-updated the plugin and then went to the SuperCache admin page looking for the instructions for “advanced-cache.php” and there was nothing to be found, only the usual instructions for uninstalling. I then checked “advanced-cache.php” on the server and it appears to have been automatically updated with the plugin. I’m taking it that just visiting the admin page does the trick?

And I have been known to be dense at times…

The other minor thing I noticed was that the garbage collection times are not the same as my time zone (UTC-5) but rather 2 hours behind and every time I refresh the SuperCache admin page the Last and Next times change (expire time is set to 1200 seconds). Not to sure if this is what I’m supposed to be seeing.

Otherwise 0.9 seems to be running great. And as always, thanks for all your work on this plugin. It’s an absolute must for for folks running on shared servers.

I’m really impressed with the constant development of super-cache. It’s a lifesaver for one of my blogs and I use it for all of my WordPress installs that get more than 500 visitors/day.

500 visitors a day should be okay without supercache. But sometimes, you can get unexpected thousands of hits a day (from social bookmarking sites). My blog went down last time because of this – that was before I knew about SuperCache 🙁

Hi Donncha,

Thanks for all your hard work on WP-Super-Cache. I really love the fact 0.9 is now mobile foolproof; you won’t know how excited I was when I read the new announcement 😀

I have two questions though:
– Does WPSP 0.9 account for the fact that I have two different mobile plugins to cater different mobile browsers? (iPhone/iPod/Android is served by wpTouch, all others are served by WordPress Mobile (Andy Moore’s one, not Alex King’s).
– Do we still need to list all the mobile UA strings in the ‘Rejected User Agents’ textfield in Super Cache’s settings page?

Thanks for answering!

I’ve experimented with SuperCache on site with about 400 visitors a day. Fast load, but eventually site was down with “internal server error 500”. So, I had have to remove this plugin and error disappeared.

Glad to see WP Super Cache coming along, it seems to have some great features and speed now. I’m still confused whether I should switch from WP Cache 2.1.2 on my WordPress 2.7. WP Cache hasn’t been updated for at least a year but it hasn’t broken anything for me.

Is it inevitable that a new WordPress will break it? And should I switch to WP Super Cache because it seems to be moving forward in sync with the latest WordPress code/features?


Jean-Paul – the mobile detection function returns a string identifying the device so iPhone will be returned for iPhone and iPod for an iPod, etc. It makes caching for these devices less efficient but more flexible and will suit your setup.

You can remove the mobile UA strings from that textbox!

defs – check the readme.txt, obviously something wrong on your server.

Kirk – you’ll only get a message if there’s an error. That time difference is the time on your server.

Alan – you should switch.

Chris – it’s not normal. I don’t know why that happens to you except that your server is probably overloaded and can’t cope with the traffic regenerating the cache.

David – you haven’t tried those plugins and the new plugin have you? They should be supported because of the way the detection is done.

ismyblog says this: Your blog application doesn’t support gzip compression.
wpsc says this:

I’m not sure who to believe. I manually un and reinstalled, but no help. I know the server has no problem with gzip because compression on the SMF/mkportal forum works fine.

There’s also this from IMBW: Page generation time: 320 ms, Page fetch time: 396 ms. That’s my SMF test forum with mkportal. Page generation time: 1822 ms, Page fetch time: 2048 ms (I once saw 4998ms!). That’s my blog, with wpsc full on with compression. With wpsc off and uninstalled, the generation/fetch speeds aren’t much faster.

The forum and blog are on the same server, db is localhost for both – about the only difference is the db name and user. I am using the free velocix accellerator CDN service, but if that was the problem the forum would be affected too. WP is molasses slow with supercache on or off.

I also see on the wpsc admin page source that there’s a missing before the sc compression fieldset.

Gah, the html got stripped. wpsc says this: — Cached page generated by WP-Super-Cache on 2009-01-28 04:31:27 — — Compression = gzip —

And I also see on the wpsc admin page source that there’s a (/p) missing before the sc compression fieldset.

Thanks for the update.

The mobile device detection is a good new feature, but I think it can be improved to allow the full on mode.
The htaccess file can be used to detect whether or not the user-agent is mobile, with the HTTP_USER_AGENT variable. Then, the redirection to mobile content can be done without any PHP code.
Do you think that’s possible ?

Ghusse – it’s possible and I thought about it for about 10 seconds before I remembered what a pain it was interacting with the .htaccess file. Maybe sometime in the future.

Hey Donncha,

I suppose this is a feature request. How about having seperate buttons to delete supercached files and regular cache files.

I make on average 50 new posts per day and I get 20,000 uniques ……about 25% of those folks leave comments.

My DB is getting frightening to look at. About 800mb with 120,000 posts and 350,000+ comments. 🙁

Donncha: First, thanks for your quick answers. I see what you mean and this is perfect for my needs.

Re: Ghusse’s question: A very knowledgeable PHP friend once wrote me some patches for WP-Super-Cache to deal with the mobile themes on my website (also the reason why I’m still using Super Cache 0.6.5 :(, since I didn’t want to mess with his patches. Seeing your new improvements in regard to mobile browsers I’m definitely consider upgrading, but his patches also worked in Full Mode for mobile (and yes, it involved some extra .htaccess rules).

If you want I can send you the patches and the specific changes to .htaccess for you to review and eventually incorporate? Please shoot me a email if you’d like to have them or let me know any other way how to get these to you. Thanks.

Since upgrading to 0.9 from 0.8.7, I’m experiencing a strange problem.

My main site is running perfectly with 0.9. However, I have a backup process that dumps the MySQL database, saves the plugin configuration and data files, and then reconstructs the website on my test server using subversion. When I try to access the copy of the website on the test server, I get the “White Screen of Death”. Death screen occurs everywhere: admin and blog pages.

After playing with different things, I discovered that I could get the test instance running again if I comment out “define(‘WP-CACHE’, true);” in wp-config.php.

But when I go to the wp-super-cache admin screen, it complains about the missing line and won’t allow me to configure super cache. But if I put back the WP-CACHE line, I get the death screen again.

Any thoughts?

Leave a Reply to Louie Alvarez Cancel reply