WordPress MU 2.8.5.1

Update! WordPress MU 2.8.5.2 has a tiny fix for a post publish bug. You can download it from the usual place.

WordPress MU 2.8.5.1 has just been released and may be downloaded immediately.

This is a security and bugfix release and a recommended upgrade for every WordPress MU site. What happened to 2.8.5? I had it tagged and ready for release when Luke reported a little problem. It wasn’t possible to edit blogs! It was an easy bug to fix but code had been tagged and zip/tarball archives created so I had to create new ones. Thanks Luke! Saved the day. 🙂

Thanks to everyone else who contributed and helped in any way during the making of this release. Your help is invaluable.

This release also fixes a problem with slashes in blog and site options. You’ll be prompted to run the site upgrader. Please run it on all your blogs. For a more comprehensive look at what has changed recently, take a look at the Trac Timeline.

Exploit Scanner 0.5

The WordPress Exploit Scanner has been updated, with lots of help from Jon and Ryan.

In recent weeks blogs running older versions of WordPress were exploited. If you’re concerned that your blog might have been broken into, download the plugin and run it. It will find false positive results but it will do a reasonably good job of finding the code that’s inserted into a hacked site.

The plugin works by scanning every directory on your site. This is done recursively which unfortunately takes up quite a bi of memory. If you get an out of memory error please read the readme.txt as it has a suggestion for fixing the problem.

PS. WordPress 2.8.5 was released last night. Make sure you upgrade! A WordPress MU release will follow shortly.

WP Super Cache 0.9.7

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.

wp-super-cache-list

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

wp-super-cache-debug

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!

Pigs help translate your plugin

I’m in the middle of translating the WP Super Cache plugin (one of my goals before a 1.0 release). The docs make it easy to understand how to do it, but it is such a chore when there is so much text. According to Vim, I’m about 25% of the way through wp-cache.php

Checking to make sure that all the strings are translated is tiresome but the Pig Latin plugin makes it easier to spot untranslatable strings:

supercache1

supercache2

There will be a new release of supercache soon, but check out the download page and grab the development version if you want an exclusive look at the new debugger, “newest cached files” listing and bug fixes.

WordPress Upgrade Notifications by Email

This weekend will go down in history. It’s the first time I’ve been seriously sick in well over 5 years. A bug infected my son on Wednesday, but he got over it quickly enough. Then the same bug hit my wife and I on Sunday morning and we’re just getting over it now.

Odd that a worm attacks software I work on and I get very sick at the same time. Unfortunately I couldn’t run an exploit scanner and remove the bug but my body’s defenses took care of the bugs eventually.

All this leads me to a handy little plugin called Upgrade Notification by Email written by Konrad Karpieszuk. Install it on your blogs and it will check once a day if a new version of WordPress is out. When that happens it will email the admin with a message saying the blog must be upgraded.

It’s odd that the plugin itself contacts WordPress.org instead of relying on the built-in version checker but it’s only one request a day.

What I’d like to see next is a direct link to the upgrade page on the blog.

Far more challenging would be a plugin to auto upgrade a blog. In case a theme or plugin breaks things the plugin should probably deactivate all plugins and change the theme back to the default theme. Once the upgrade is complete, all plugins should be reactivated and the theme too. The admin has to be emailed before and after the upgrade.

It’s easy to say what it should do, but doing it is another thing altogether. The reactivation process has to be sandboxed in case of failure so the plugin doesn’t die. The plugins page already does this so at least there’s example code to work from. Anyone up for coding it?

WordPress MU 2.8.4

WordPress MU is a multi user or multi blog version of WordPress that is used to run sites like WordPress.com.

Today’s WordPress MU release is 2.8.4, a security release that fixes an annoying bug that allowed any user to reset the admin password. Your password was never at risk however so it’s more an annoyance than anything else.

Oh, thanks to everyone who tested the exploit on my blog. See? You didn’t get my password! 😛

Upgrade automatically from within your dashboard (first fix the upgrader if you haven’t updated to 2.8.3 yet), or download the new release from the download page and upgrade manually, overwriting your current install with the new files.

Edit: James Collins noticed that line 164 of wp-login.php wasn’t merged properly. If you downloaded 2.8.4, please grab 2.8.4a. Thanks James for the prompt feedback!

WordPress MU 2.8.3

WordPress MU is a multi user or multi blog version of WordPress that is used to run sites like WordPress.com.

WordPress MU 2.8.3 is a security and bugfix release based on the fixes in WordPress 2.8.3 but also contains many other changes.

It’s a required upgrade for security reasons but also fixes a number of annoying bugs, especially #1067 and #1076.

Unfortunately the automatic upgrader in MU 2.8.2 is broken but it’s simple to fix:

  • Before upgrading, edit wp-admin/includes/class-wp-upgrader.php and look for line 697.

    if ( !$wp_filesystem->copy($working_dir . ‘/wordpress/wp-admin/includes/update-core.php’, $wp_dir . ‘wp-admin/includes/update-core.php’, true) ) {

  • See the “/wordpress/wp-admin/includes” bit? Change that to “/wordpress-mu/wp-admin/includes”:

    if ( !$wp_filesystem->copy($working_dir . ‘/wordpress-mu/wp-admin/includes/update-core.php’, $wp_dir . ‘wp-admin/includes/update-core.php’, true) ) {

  • Save the file and auto upgrade. I upgraded this afternoon without a hitch after making that change. It’s fixed in 2.8.3 so it’s the last time you’ll have to do it.

Do not copy and paste the line above as WordPress will have changed the quotes to “smart quotes”. Actually go in and type “-mu” after “wordpress”. No copy and pasting please!

If auto upgrading still doesn’t work, don’t sweat it. Download the new release from the download page and upgrade manually, overwriting your current install with the new files.

WP Super Cache 0.9.6.1

WP Super Cache 0.9.6.1 is now available.

This release adds the following menu item to the admin page.

page_types

You can now choose to not cache different types of pages on your blog. Don’t want to cache your front page? That’s easy now. The indented page types are types covered by the top type. “Archives” covers “Tag” and “Category” pages for example.
See the Conditional Tags codex page for a description of the page types, especially “front page” and “home”.

I also fixed a few bugs, including the AYS problem saving posts which was a problem if you had “Don’t cache for logged in users” enabled.

I never got around to blogging about 0.9.6 but that included an uninstall script that deletes the folders and files created by wp-super-cache. Make sure you read the readme.txt before running it. For security reasons you have to edit the script before using it.

I also updated the mod_rewrite rules in cache/.htaccess (Thanks Andrew!) For some reason the web server forgets the mime type it’s supposed to serve gzipped supercache files as. It should be “text/html” in the cache dir but randomly and on the odd occasion it reverts to the gzip mime type. I examined the cache files when this happens and they look correct. Clearing the cache dir fixes the problem temporarily (and file sizes match before and after). I can’t explain it.
Remove cache/.htaccess if you see this happen (you might need to use the uninstall script) and reload the admin page to regenerate the file. The new rules force the mime type in a different way. Hopefully Apache won’t forget it this time.

Win a trip to Disneyland

I’ve got good news, and I’ve got great news! The good news is for spammers. The great news is for you.

The good news is that in 3 simple steps you too could win a trip to Disneyland:

  • Visit one of those sites that lists this blog as a dofollow blog (BTW – it doesn’t dofollow anymore)
  • Click on a link to my blog.
  • Have a great time in Disneyland!

The great news is that you can send those spammers to Disneyland too! Just take a look at the code in disney.txt and copy it into your wp-config.php (Put it right at the top of the file!) or into an auto_prepend file.

The $bad_referrers array is a simple list of offending sites that send you the most spammers. Add them in and when the spammer comes visiting they’ll be whisked off to Disneyland for a magical tour of the castle. (Hopefully they’ll meet an ogre who’ll take a fancy to them and lock them in the tower or something!)

I use my Comment Referrers WordPress plugin to tell me where comment authors come from but sometimes if they’ve browsed around my site (and the referrer is gone then), I search my logs for their IP address.

Yes, the above could be done with .htaccess mod_rewrite rules but this is more portable and I redirect to a Pretty Link shortcut so I can easily count the hits. No matter what I did I couldn’t get it to exclude the hit to the shortcut and it would redirect continuously.

Update! I added rewrite rules to send the spammers off. I’m sure these rules can be improved so leave a comment if you have any tips.

RewriteCond %{HTTP_REFERER} .*theseomizer.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*seomizeme.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*revolutioners.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*rishabhsood.net.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*011831068587400451950.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*backlinkmagic.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*www.online-utility.org/webmaster/backlink_domain_analyzer.jsp.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*forums.digitalpoint.com/showthread.php?t=1011238.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*courtneytuttle.com/blogs-that-follow/.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*forums.digitalpoint.com/showthread.php?t=1006727.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*forums.digitalpoint.com/showthread.php?t=1003675.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*rasimcoskun.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*smartpagerank.com.* [NC]
RewriteRule ^(.*) http://disney.com/ [R,L]

And in other news, Stephen Cronin created the comment warning plugin to warn visitors who come from predefined urls like the dofollow lists above. Nice!

WordPress MU 2.8.2

WordPress MU 2.8.2 has just been released. This is a security release with the same fix as the standalone WordPress.

WordPress 2.8.2 fixes an XSS vulnerability. Comment author URLs were not fully sanitized when displayed in the admin. This could be exploited to redirect you away from the admin to another site.

This release also fixes a number of other bugs, most notably the upgrade notice, but also fixes a number of other problems. See the timeline for a record of the latest activity.

Grab the new release from the download page or upgrade automatically from within WordPress MU.