WP Super Cache version 0.9.8 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.
New in this release are 2 translations. The Spanish translation is by Omi and the Italian by Gianni Diurno. Please, if you use their translations, drop by their sites and leave a thank you comment! They’ve been very patient with me as I fixed gettext bugs and added new text. Both have blogged about the translations if you need to know more: Gianni, Omi.
The second major feature to go in is an “advanced” section to the debugger. This allows the plugin to check the front page every 5 minutes to make sure everything is ok. It monitors for 2 very rare problems:
- Very very occasionally, the front page becomes a gzip file that downloads. It happened here once and I examined the cache file. There was nothing wrong with it. It was perfect. I suspect Apache and mod_rewrite got confused somehow but clearing the cache fixed it. The file generated after was exactly the same size as the old one, so no chance it got “double gzipped”.
- In certain rare cases, where a blog has a static front page, and uses a permalink structure of /%category%/%postname%/, the wrong page may be cached as the front page. Even if your blog satisfies the two conditions above it may not suffer from this problem. I tried it on this blog for a few days and couldn’t reproduce it at all!
Nevertheless, if you’re concerned edit your wp-cache-config.php and add this line:
$wp_super_cache_advanced_debug = 1;
Reload the admin page and you’ll see this added to the debug section:
If activated, it will check your front page every 5 minutes. It’s not activated by default because these errors only happen to a small number of blogs. I’ve also noticed that WordPress seems to randomly forget to run the page checker from time to time. I debugged it and the job simply disappears from the wp-cron system! I’ve no idea why, but reloading the admin page schedules it again.
If you’re still paranoid, set your cache expiry low so at least the cache files will be recycled quickly.
Caching, Minification and CDNs
Oh, there’s a new caching plugin on the scene. W3 Total Cache works like Supercache’s half-on mode but can store to memory as well as disk (like Batcache) but also does minification and supports CDNs. I’ve been asked a few times if I’ll support those features too but I don’t see why as other plugins already have that covered (and frankly, I don’t have time to maintain such complex features):
- WP Minify “integrates the Minify engine into your WordPress blog. Once enabled, this plugin will combine and compress JS and CSS files to improve page load time.” Thaya is very responsive and fixed a bug I reported quickly.
- There are any number of CDN plugins for WordPress. I don’t use a CDN so I can’t recommend one but OSSDL CDN Off Linker might be worth a shot. This post on it mentions Supercache plus, a fork of this plugin.
Traffic Spikes and Benchmarks
I really should collect more of these. A few weeks ago Mark Pilgrim blogged about how his book had been republished by a 3rd party and put up for sale on Amazon. His book was published under the GNU Free Documentation License so that’s perfectly legal to do, even if a little unusual as it can be downloaded from Mark’s website and is for sale by his publisher. The blog post generated a lot of interest and a few days later I received a donation from Mark, followed by a thank you email. I’m a big fan of what Mark does, so if it had been a physical cheque or a letter I’d have framed it!
A few days after that he tweeted the following graph. Nice spike of traffic eh? His server held up fine with help from WP Super Cache.
And finally, some benchmarks, in Russian unfortunately but the pages translates well.
- WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache (translation) shows Supercache doing 106154.90 requests a second, but that’s thanks to using Nginx too.
- WP Super Cache vs MaxSite Cache: Part 1 (translation) shows a tight race between Supercache and a plugin called Max Cache Lite, probably because he used Apache this time.
Summary of changes in 0.9.8:
- Added Spanish translation by Omi.
- Added Italian translation by Gianni Diurno.
- Addded advanced debug code to check front page for category problem. Enable by setting $wp_super_cache_advanced_debug to 1 in the config file.
- Fixed wordpress vs wordpress_logged_in cookie mismatch in cookie checking function.
- Correctly check if WP_CACHE is set or not. PHP is weird.
- Added wp_cache_clear_cache() to clear out cache directory.
- Only show logged in message when debugging enabled.
- Added troubleshooting point 20. PHP vs Apache user.
- Fixed problem deleting cache file.
- Don’t delete cache files when moderated comments are deleted.
PS. WordCamp Ireland is on in early March next year in picturesque Kilkenny. Here’s Sabrina’s launch post. Sign up! I’ll be going!
Hi Donncha,
I had to disable your plugin because it broke my site. When activated – the entire section of my pages disappears. Now during de-activate mode, I’m unable to delete the plugin. I know that there is an uninstall script available but I’m afraid to enable it because it breaks my pages. Any advise on how to take it out without re-activating?
Read through the “If all else fails” section of the readme.txt and it will explain how to remove it.
I love WP Super Cache. I took a picture of my Google Analytics when I weathered the Great Daring Fireballing of September ’09. Check it out here: http://jwr.cc/x/1m
Jay – that link didn’t work for me. Got another one?
I almost forgot, there’s also Really Static, another caching plugin which turns WordPress into a totally static site.
That’s because MAX (the author of MaxSite Cache) said that WP Super Cache was better only because I have properly tuned the server. He said that the majority of the bloggers (those who buy VDS) do not have the skills to configure and tune the server – they just use the configuration which came out of the box.
I have deployed a test VDS server with 512 MB RAM (Ubuntu 8.04 Server Edition with preinstalled Apache + PHP5 + MySQL), configured mod_rewrite and installed WordPress.
MaxSite Cache Lite was better at creating the cache (because it is very very simple) but WP Super Cache was better at serving the cache.
The second part of the “cache battle” will be on the same VDS but it will be properly configured. I think that the results will differ greatly 🙂
Vladimir – thanks for dropping by and commenting! I look forward to seeing the second part. Can you leave a comment here when you post it?
Next on the list for this blog is moving to Nginx, but I have my VAT return to do tonight. Bah. Money for the poor tax man.
The second part is here.
Hey Donncha.
Been using this plugin for many upgrades now without a hitch, but this latest upgrade totally broke my blog too. Fixed it as per your suggestion above, but thought you’d like to know.
Cheers.
Hey Donncha,
thanks for all your hard PHP work!!!
WP Super Chache its use is far less complicated than DB Chache Reloaded, What I found in the field of DB Chache Reloaded requested write file permissions 755 on the folder WP-Content and config.ini but for me it hosting can not be done, any suggestion?
Hi Donncha,
Thanks a lot for such a wonderful plugin. I’m using this on my 3 blogs since last almost 2 years.
-Arpit Shah
I love WP Super Cache. I took a picture of my Google Analytics when I weathered the Great Daring Fireballing of September ’09.
Here ya go: http://jwr.cc/x/1n
I’ve used WP Super Cache for a few days, then I see that my Adsense revenue has dropped dramatically. Is there any problem with this plugin, does it affect Adsense’s Ads?
No, it doesn’t affect ads being served at all. I’ve been using it here for 2 years+ and my ad views have been consistent with page views.
Oh, thanks very much!
I want to ask you another question. Since I used Super Cache, the WP User Online plugin doesn’t work any more. Do you have any solution to solve this?
There is a solution, the plugin has to be rewritten unfortunately. I covered this in the FAQ in the readme.txt
here is the finally version of WP Super Cache 0.9.8 chinese simple pack urls:http://wordpress.org.cn/thread-49453-1-1.html
Another win for Donncha. I think for now I’m going to stick with WP Super Cache.
And I think you’re going to love nginx.
under Directly Cached Files i keep getting this error: “Warning! …… (the add-on domain name folder where wp and super cache are installed) is writable. Please make it readonly after your page is generated as this is a security risk.”
That domain’s folder shows permissions as 755 so I do not understand where the problem lies. I can’t find the solution here or anywhere. not sure what to do as I am a recent WP user/novice on a steep learning curve.
thank you for your help.
the domain is hosted on netfirms if that tells you anything (which is also why I installed wp super cache b/c I think their servers are pretty slow?)
One of the sites we host was getting the weird non-homepage homepage error. We ended up disabling cache on the homepage (both is_home and is_frontpage) and it seems to have resolved it. Of course that means one page won’t get cached but with caching everywhere else it seems to hold up OK.
Hello Donncha,
I was wondering how it would be possible to fix the issue with apache. The plugin generates what looks to be a gzip page at first. http://i47.tinypic.com/2nvz3h1.png. Thanks!
I don’t know how to fix it because I can’t reproduce it successfully here. Read my post above for ways to mitigate the effect..
Dan,
Try disabling mod_deflate in Apache.
Hello Vladimir,
Thanks for the suggestion, however I do not have mod_defalte enabled on the server.
Donncha,
Where may I find your list of ways to mitigate the effect? I had debugger running and it seemed to not locate an issue.
Dan, what about output_handler, zlib.output_handler and zlib.output_compression in your php.ini?
Vladimir, output_handler has no value. However, zlib has this – http://i46.tinypic.com/4rz6v5.png. Thanks Again!
Well, just turn off zlib.output_compression then 🙂 This should solve the problem
Vladimir,
I appreciate your help! 🙂 However, I’ve created a custom php.ini disabling
zlib.output_compression, yet the problem is still occuring. 🙁
if you are using Apache, hardly will mod_php pick up your php.ini. I guess you need to create/modify your .htaccess file in your webroot/WordPress root and add this line to it:
php_flag zlib.output_compression off
Then you need to verify with phpinfo() that the compression is really turned off (because the above may not work if you are using, say, mod_mpm_itk etc).
Alternatively you can try adding
ini_set('zlib.output_compression', 0);
somewhere in the top of your wp_config.php (hopefully safe mode is off).
Vladimir,
Thank You for all your help! The .htaccess did it. :-). Have a Wonderful Christmas!
Thanks, you too! 🙂
Vladimir – I’m sure that setting can be detected from within PHP. The plugin should warn the user if they try to enable compression.
Donncha,
The plugin did not warn me that compression was enabled. I’ve used earlier versions of your plugin and they worked perfectly in the past. Keep up the good work! 😀
Donncha, why are you using
apache_request_headers()function instead of$_SERVER['HTTP_USER_AGENT']inwp_cache_user_agent_is_rejected()?apache_request_headers()is not available for all SAPIs.It’s ok, I define that function in wp-cache.php if it doesn’t exist.
Hey Donncha, we’ve been experiencing some strange problems with the interaction between wp-mobile-edition and wp-supercache. I’ve carefully checked that all the .htaccess files are correctly written and the mobile support option is checked but we are still seeing some posts getting cached in mobile format and shown to desktop browser users.
I’m going to do some more testing with the debugging, but was wondering if you’ve been hearing about this from other people or have other advice?
Maybe a solution would be to just block all mobile user agents from caching in the “Rejected User Agents” section? Would that work? Maybe just set the DONOTCACHEPAGE constant at ‘init’ if the mobile edition plugin claims its a mobile page?
So i’m looking into it more and from what I can tell your list of mobile browsers used to generate the .htaccess files is completely hardcoded into the wp-cache.php file.
I can’t understand exactly what is happening in the .htaccess file, but it seems like this is a recipe for disaster. It means that if the user agent strings set in wp-cache.php differ from the ones set in the options for WP-Mobile-Edition then those strings that are only in the Mobile Edition settings will effectively get ignored by whatever is happening in .htaccess.
I have a feeling this is what is causing the intermittent bugs we’ve been experiencing. When I try it with my iPhone it works fine because my iPhone user-agent is accounted for in Supercache. But when someone with one of the unsynced user-agents comes Supercache saves the mobile version of the site as a regular cache.
When you first added mobile support, did you just copy the default user-agents from wp-mobile-edition? If so you should at least update the list, as many have been added, notably the ‘Googlebot-Mobile’ user agent, which sounds like it might come by often to cause problems.
Ideally Supercache should recheck the saved list of mobile user agents from mobile-edition regularly to make sure they match. The .htaccess part of Supercache should be auto-generated from that list and the user shoudl be reminded to update their .htaccess if the lists dont’ match.
Hope this makes sense, any insight is very welcome.
Yeah, I copied the user agents from there. I’ll download it again and update them.
Did you update the user agents in the .htaccess file? I can make the plugin check the list of mobile user agents in that file but I shy away from updating it automatically.
I’m not very confident about my ability to edit the regex without borking it so I haven’t updated it manually yet.
IMHO if you apply the same principle to this issue as you do to the general ‘your .htaccess is out of date cause you turned on mobile support’ situation then I think that’s good enough. Just tell people that they should update it manually based on what’s in the htaccess box. If they notice the problem then they come to the Supercache settings at which point they get the notice.
It might be good to be kind of aggressive about notifying people though (show that message in dashboard and not just on the supercache settings). Now that the setting to not cache logged-in pageviews is there I think a lot of people are completely unnaware that the mobile issue exists because they never see the cached (mobile) version of their sites. My org only noticed cause outsiders were telling us there was a problem, we had hundreds of users all logged in and oblivious to the problem.
Temporary Solution
For anyone else experiencing the problem I came up with some plugin code (functions.php should be a viable place to put it) that fixes the problem temporarily by stopping supercache from ever caching mobile pages.
Here it is: http://pastie.org/788981
Using this means you don’t benefit from caching for mobile users, they will always generate their views fresh, but your normal users won’t ever see the mobile version. It seems that doing this doesn’t interfere with the user-agents that Supercache accounts for (iphone,ipod, android, all the major players), so they will still consistently show the mobile version of the site. For user agents that Supercache isn’t aware of (new ones in mobile-edition or ones you added yourself) they will be sent to any pages that were supercached in the general pool (i.e. normal theme), but if they visit a url that hasn’t been supercached they will see the mobile version.
I’m not sure but maybe using that code inside supercache itself would make sense. Especially if combined with whatever mobile checking you are doing in supercache. I.e. IF mobile-edition thinks its mobile AND Supercache DOESNT think its mobile then don’t cache the file. That situation theoretically shouldn’t exist, and in practice that situation is exactly the one that is creating the bug.
Check out trunk, or the dev version. That will grab the list of mobile UAs from wp-mobile-edition if the right function exists.
Beware because trunk is where the object cache version is too, activate it if you’re brave!