wp-super-cache – Page 6 – Something Odd!

WP Super Cache 0.8.7

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

This release addresses some issues large or busy sites had with deleting expired cache files. Some sites generated so many cache files that there were two many files generated, even when those files were cleared out every hour. To fix that I limited the recursive function that deletes the files to 100 deletions at a time. That function is called until all the cache files are deleted (or strictly speaking, no files are deleted. That’s how the expired file cleanup works).
It’s also possible to set the garbage collection interval to 10 minutes now which will also help.

WordPress MU 2.6.5

WordPress MU, the multi blog version of WordPress that runs on such sites as WordPress.com has been updated to version 2.6.5 to address an XSS vulnerability in the feeds offered to users.

More details will be forthcoming but for the time being, there’s also the WordPress.org announcement post.

This release also has a number of bug fixes, including a fix and improvements to rss caching. This is a required upgrade, so please install it as soon as you can.

After you’ve upgraded, check out the nominations for the 2008 WPMU Awards and vote for your favourite!

In related news, a new version of WP Super Cache is also available. This version hopefully fixes:

Issues with clients seeing compressed pages incorrectly
Cache clean up
Warnings if Apache modules are missing
Better support for WordPress MU. The wp-content/cache/.htaccess rules are now displayed on the admin page
Better documentation on file locking
WP Cache files are written to a temporary file first
Use WP_CONTENT_URL in mod_rewrite rules generator

It also adds a number of filters:

“supercache_dir” filter so the supercache directory can be manipulated. “wp_cache_key” cache_action to modify the key the wp-cache file is named after. Using both of these should make it easier for plugin authors to manipulate the cache based on user agent or other criteria. ie. iPhone theme? Unfortunately .htaccess rewrite rules will have to be updated manually.
Added “wpsupercache_buffer” filter so the current page can be manipulated before being stored in the cache.

WP Super Cache 0.8.4, the garbage collector

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

This is a minor release but was prompted by White Shadow. He released a plugin that cleans up expired cache files on a periodic basis instead of after X number of hits. Great minds think alike, (or fools seldom differ) because I had the same idea a few weeks ago and had the code running on this blog for that time without any problems.

The garbage collection system should have operated this way in the first place, but at least now it’s easier to configure.

WP Super Cache 0.8.3 "Speedy"

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

Double Caching

This releases fixes a long standing compression bug. In older versions of the plugin, the cached page was compressed twice. Once to display to the current visitor, and once again for the cached files stored on the server. This has now been fixed and there’s a noticeable speed increase for anonymous visitors. Unfortunately as a side effect, it’s not possible to display the “super cache gz” html comment now. To verify that html pages are being served from the supercache directory you’ll have to add an error_log() somewhere and check that visits aren’t logged.
The plugin now uses fopen() instead of gzopen() which according to a comment on the gzopen() manual page is unreliable under high load.

IE7 Fixes

Apparently IE7 has problems when gzipped files are served as “x-gzip” files, under certain circumstances. This is an obscure bug but this has been fixed. If you’re upgrading, either remove wp-content/cache/.htaccess and visit the admin page and that file will be regenerated, or edit that file and change “x-gzip” to “gzip”.

A number of smaller bugs were also fixed. Check the changelog for further info.

Want to test super speed caching?

Yesterday morning was one of those mornings. I couldn’t sleep, but not for want of trying. Around 5am our 17 month old baby wasn’t too keen on the whole notion of shut-eye. Instead I took him downstairs to feed him, and do a little surfing and hacking to pass the time until the sun rose.

Lucky for you that I did.

I discovered that WP Super Cache was compressing the page output twice! That’s right, it’s my own fault, but for over a year that little bug has gone unnoticed. I won’t bore you with details, but it’s fixed now and if you compare wp-cache-phase2.php from the latest release with that in the development version you’ll spot the differences.

In testing, I noticed that pages were generated more quickly. Sometimes twice as fast as before if everything else had been cached by the object cache. I even posted a message to the support forum asking people to try it out but the silence is deafening which is why I’m turning to the power of the blog post.

If you’d like to give this bit of code a go, grab the development version of WP Super Cache, test it, and leave a comment here. Before you install it, grab a few pages while not logged in and record the page generation time, then after install, check out the same pages. I’d love to hear if it improves things.

You could also try setting “$cache_rebuild_files” to 1 in wp-cache-config.php. That will enable some experimental code that moves supercache files out of the way when the page becomes stale but then restores them while the page is being rebuilt. That should help significantly on busy sites where lots of comments are made. It’ll be switched off by default because I don’t think it will benefit most sites, and will only result in more I/O. Check out this forum thread for further info.

If you’re interested in testing the plugin in the future, you could subscribe to the wp-super-cache-dev tag, where I’ll post development updates on the plugin.

WP Super Cache 0.8

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

If you’re not interested in the changes, simply grab the latest version of the plugin and copy the files into your plugin folder. It’ll work, but if you’re upgrading, you should read on.

Major changes in this release:

Generate a semaphore id based on hostname and cache path to avoid problems on shared hosts, props Tigertech.
If you run WordPress from a different directory to where it’s installed, supercached files weren’t deleted when a post was made or updated. That is now fixed. Thanks Viper007Bond for all your help on that.
Paged archives, category pages, and tag pages are now cleared when a post is edited or comment approved. This replicates what WP Cache did all along so you should hopefully see supercached static files updating more often.
If your .htaccess is read-only, the mod_rewrite rules are displayed on the admin page. Thanks Matt for the patch.
Updated mod_rewrite rules won’t serve static html files if there’s a “=” in the url. Should catch all sorts of problems with plugins and attachments. You’ll have to manually edit your root .htaccess to match the new rules.
Set cache control and expiry headers of supercached files. They are cached for 5 minutes, but with a “must-revalidate” header. Delete wp-content/cache/.htaccess for the new rules to be updated.
Check for WordPress MU because it can’t update the .htaccess file.
Write supercache html to temporary files and rename. The old way opened the correct file for writing, did some work and wrote the file. In the fraction of a second it took to write the file, someone might request it and get an incomplete page.
The Supercache expiry time has been removed. There can be only one.

Edit: 0.8.1 has just been released. This addresses the following:

The “forbidden files” problems some users had is fixed.
Supercache files were being removed needlessly when a moderated comment was made.
I added a “Clear cached files when post is edited” checkbox.
I added a “Delete Cache” link next to the Dashboard link on the dashboard.
Tigertech found that when a file is renamed and the new filename is already used, the old remains.
Updated readme.txt.

WP Super Cache 0.7 – the dupe content killer

WordPress.org user, “definitelynot” discovered a bug in the WordPress plugin, WP Super Cache that could expose blogs to duplicate content penalties. Unfortunately this affects every blog that uses the plugin in “ON” or full “Super Cache” mode, and has URLs that end with the “/” (forward slash) character. If the plugin is on “half on” mode, you’ll be fine.

The problem is that an anonymous user might visit a legitimate URL, ending with a slash, the plugin then creates a static file out of that page, which is then used when people visit the same URL. Unfortunately if someone links to that URL without the ending slash, a visiting browser or search engine bot won’t be redirected to the proper URL, they’ll be served the static html file.

For example:

John visits the URL /2007/05/23/why-the-nurses-cant-go-on-strike/ on my site. WP Super Cache creates a html file of that page.
In his enthusiasm for that post, John publishes a post about those zany doctors, but he forgets the ending “/”.
Googlebot, seeing fresh content on John’s site, crawls it and sees the link, visits my site eventually and wonders why it’s seeing the exact same page at two different URLs.

To be fair, Google is pretty good at figuring out where duplicate content is supposed to go but it’s better to avoid the issue completely. It also only matters if there are links to your site without the ending slash. The most common will probably be to your homepage as it’s likely internal URLs will be copy/pasted.

How to Fix
You should update to version 0.7 of the plugin which checks if your blog is affected by this problem. It also has instructions for updating the mod_rewrite rules in your .htaccess. It’s fairly easy to fix. Thank you “andylav” for the mod rewrite magic!

Edit the .htaccess in the root of your WordPress install.

You’ll see two groups of rules that look like this:

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]

You need to add the following 2 rules above each block of “RewriteCond” lines:
```
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
```

The rules should eventually look like this:

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]

Or you could just delete those rules and let the plugin regenerate them for you again.

PS. Thanks also to Lloyd for noticing the “enable the plugin” link was pointing at the wrong URL, and to Ryan who spotted a minor problem with the admin page and was kind enough to send me a Tweet about it.
PPS. I’ve just tagged 0.7.1 to fix some problems with the updating of the .htaccess, mainly for new users. If 0.7 of the plugin works for you, there’s no need to upgrade!

WP Super Cache 0.6.7

WP Super Cache is a plugin for WordPress that creates cached copies of your blog posts and pages, making your site much faster to serve. It’s also ideal for coping with sudden surges of traffic.

I released a new version of the plugin this morning. This is a bugfix release:

Mike Beggs contributed a number of changes:
1. Better support for Win32 NTFS
2. Better use of the “Vary” header so proxy servers won’t cache the wrong page. If you see leakage of comment details on posts this will fix that problem.
3. WP-Cron handles cleanup of expired cache files in the background now.
4. Disable mod_deflate if it’s running as it sometimes tries to compress gzipped files. Remove wp-content/cache/.htaccess for that file to be updated.
Lazy and Otto both recommended using get_comment() instead of the depreciated get_commentdata()
A basic “uninstall” function has been added to remove some of the files the plugin creates. It’s called when you deactivate the plugin.
PHP running as a CGI doesn’t support apache_request_headers() so that’s been added too.
And I almost forgot, the admin page received a slight makeover.

Get the plugin from the download page!

WordPress at No. 10

You may have heard that the official site of the British Prime Minister’s Office at number10.gov.uk launched earlier today. The great news is that it’s running WordPress, but what really excited me is the fact that the site is also using WP Super Cache.

The site was initially very slow, but once the cached static files were in place, it just zipped along! Three cheers for caching and everyone who has contributed to WP Cache and WP Super Cache! 🙂

I wonder if Gordon Brown will be looking at his Dashboard? *Wave*

WP Super Cache 0.6.2

A few people stumbled across a strange bug in WP Super Cache. If your index.php was cached by the plugin then feeds or other pages that hadn’t been cached would show the front page!

A simple way to fix this is by adding “index.php” to the list of rejected URIs, but then it won’t be cached at all. This release fixes the problem but also allows index.php to be cached by the WP Cache engine, much better than excluding index.php completely.

Also included is a new feature that inserts your rewrite rules in a new .htaccess block. That will stop WordPress overwriting the rules after doing an upgrade, or after changing permalinks. The plugin won’t update your .htaccess if it finds the rules already in the “WordPress” section, but if you visit your permlinks options page and hit “Save Changes” the plugin rules will be deleted. Go to the WP Super Cache admin page where you can update the rules again. They’ll be inserted in a “WPSuperCache” block above the WordPress rule block.

If all that seems a bit technical, just go to your permalinks options page and hit “Save Changes” without changing anything, then update your rewrite rules on the Super Cache options page!

Go grab the plugin from the usual place.

I never saw this obscure problem because I redirect hits to /index.php to / using this mod_rewrite rule and php code. This used to help avoid duplicate content rules but I think Google is smarter now. It probably will help reduce pagerank dilution because all requests will go to one homepage url, rather than two.