WordPress MU 2.9.1

WordPress MU version 2.9.1 has just been released.

This is probably the last release before it is merged into WordPress 3.0 as the merge has already started!

Anyway this release brings the new features and bug fixes of WordPress 2.9 and 2.9.1 into WordPress MU. My favourite new feature has to be the Trash can, but there’s also an image editor, plugins can be bulk updated and video embeds are easier to do.
If you have more than a few dozen blogs, be sure to add the commentmeta table first before upgrade.

Thank you to everyone who has helped make WordPress MU better over the years, either by helping on the forums, writing plugins, contributing code, working on Trac tickets or any of the other hundred and one other things that go into an open source project.

WPMU: Please add commentmeta first

I was going to announce WordPress MU 2.9.1 today but I knew that people would run into trouble with the missing commentmeta table if they didn’t upgrade their blogs immediately.

So, download add-commentmeta.txt, rename it to add-commentmeta.php and copy it into your mu-plugins folder. Login to your site as a Site Admin, visit Site Admin->Upgrade and upgrade all the blogs on your site. Make sure you’re using WordPress MU 2.8.6 as the upgrade script in older versions may not execute the plugin.

The script above will add the commentmeta table to each blog. Give it time because it will take quite a while on large sites. WordPress MU 2.9.1 tomorrow.

WordPress MU 2.9.1 RC

WordPress MU 2.9.1 is almost ready but we need people to test it before the final release. This will be the final release before we start merging into WordPress so I’d love to get as many bugs as possible ironed out. Take a quick look at the tickets in Trac and see if you can fix any!

Check out revision 2044 or to get the latest code get it from trunk instead. If you’re not comfortable with Subversion access, there’s a zip file at the end of each page.

Only try this on a test server of course! The new version creates a new “commentmeta” table on each blog after you upgrade. That could be intensive on large sites. Ron points towards John’s script that adds those tables. I haven’t tried it yet (it’s a job for tomorrow!) but it’s definitely a good idea to create this table on all your blogs before you upgrade. Let me know how it goes.

Sitewide Tags 0.4 for WordPress MU

If you use the Sitewide Tags plugin for WordPress MU you may have missed Ron’s announcement post about the new release.

This version is all Ron’s doing. He merged in features he has worked on over the past year. Check out his blog post for the full list of changes.

Oh yeah, I’m doing mini-merges of WordPress and MU code all the time. Update from trunk (svn link) if you want to try it out, and please report any bugs on trac! I love the new trash feature!

Could this be the last huge WP into MU code merge?

Well, this might be one of the last times I do a huge WordPress MU merge! I’ve just finished merging the code from WordPress 2.9 beta 1 into WordPress MU trunk. No, I didn’t link to the actual merge changeset. That’s 2007 and huge! 🙂

Want to give it a go? Grab the zip file from here and install it on a test server. Do not, under any circumstances install it on your production server! Be aware that I haven’t tested most of the code yet so there may have been errors made during the merge.

We also need to work out a good way of adding the commentmeta table to each blog. If your MU site has more than a few dozen blogs you need to add this table before you upgrade. On WordPress.com, it took quite a long time to add that table to each of the millions of blogs there! It’s probably something that an external plugin should handle. It’ll have to be linked from the MU download page and hopefully talked about enough that nobody tries to upgrade without it. Ideas?

Oh, I’m testing out WordPress 2.9-beta-1 and changed theme here. I’m using a heavily modified version of P2. Love it so far. I’ve managed to hack it to do what I want. Noel did a great job with the theme.

WordPress MU Domain Mapping 0.5

WordPress MU Domain Mapping is a plugin that allows the users of a WordPress MU site to use custom domains on their blogs.

It’s been a while since the last release but with the help of Ron Rennick, and many others (kgraeme – you kick ass at finding bugs!) I think the wait has been worth it. Changes since the last release:

  1. Works in VHOST or folder based installs now.
  2. Remote login added.
  3. Admin backend redirects to mapped domain by default but can redirect to original blog url.
  4. Domain redirect can be 301 or 302.
  5. List multiple mapped domains on site admin blogs page if mapped
  6. Bug fixes: set blogid of the current site’s main blog in $currentsite
  7. Bug fixes: cache domain maps correctly, blogid, not blog_id in $wpdb.
  8. and lots more bugs fixed and squashed.

There are still a few limitations however:

  1. Your WordPress MU site should be installed in the root of your server.
  2. It’s not possible to map a path on the new domain.
  3. You cannot map a domain on to the main blog in a folder install of WordPress MU.

Grab it from the page above, make sure you read the readme.txt as the plugin needs to be installed and configured correctly. You’ll also need to be familiar with concepts such as CNAME and A DNS records and how to configure your server correctly.

Please try it first on a test server. We have gone to extraordinary lengths to try to fix every bug we could but it’s always better to be careful when trying out new software.

WordPress, Nginx and WP Super Cache

If you host your own WordPress blog, it’s probably on Apache. That all fine and good. For most sites Apache works wonderfully, especially as it’s so easy to find information on it, on mod_rewrite and everything else that everyone else uses.

One of the alternatives is Nginx, a really fast webserver that streaks ahead of Apache in terms of performance, but isn’t quite as easy to use. That’s partly because Apache is the default webserver on most Linux distributions and hosts. Want to try Nginx? Here’s how.

Install Nginx. On Debian based systems that’s as easy as

aptitude install nginx

Nginx doesn’t talk PHP out of the box but one way to do it is via spawn-fcgi. Here’s where it gets complicated. (Docs summarised from here)

  1. Install php5-cgi. Again, on Debian systems, that’s
    aptitude install php5-cgi
  2. Edit /etc/nginx/sites-available/default and add the following chunk of code to the “server” section:
    location ~ \.php$ {
            include /etc/nginx/fastcgi_params;
            fastcgi_pass  127.0.0.1:9000;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME  /var/www/nginx-default$fastcgi_script_name;
    }
  3. Install lighttpd for the spawning command.
    apt-get install lighttpd

    You’ll probably get an error at the end of the install if Apache is already running on port 80. Edit /etc/lighttpd/lighttpd.conf and uncomment the line

    server.port = 80

    and change 80 to 81. Now run the apt-get command again and it will install.

    /etc/init.d/lighttpd stop

    will stop lighttpd running. (You don’t need it)

  4. Create a new text file, /usr/bin/php-fastcgi with this:
    #!/bin/sh
    /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f /usr/bin/php5-cgi

    The user “nobody” should match the user Apache runs as to make things easier to transition.
    Make it executable with

    chmod 755 /usr/bin/php-fastcgi
  5. Create another new file /etc/init.d/init-fastcgi and make it executable with the chmod command too. Put this in the file:
    #!/bin/bash
    PHP_SCRIPT=/usr/bin/php-fastcgi
    RETVAL=0
    case "$1" in
        start)
          $PHP_SCRIPT
          RETVAL=$?
      ;;
        stop)
          killall -9 php
          RETVAL=$?
      ;;
        restart)
          killall -9 php
          $PHP_SCRIPT
          RETVAL=$?
      ;;
        *)
          echo "Usage: php-fastcgi {start|stop|restart}"
          exit 1
      ;;
    esac
    exit $RETVAL
  6. Start the PHP processes with
    /etc/init.d/init-fastcgi start

    and make sure it starts on every reboot with

    update-rc.d init-fastcgi defaults

That’s the PHP part of things. In Debian, the default root is “/var/www/nginx-default” so put an index.php in there to test things out. Stop Apache and start Nginx (if this is a test server only!) and visit your site. Works? Now to get WordPress and WP Super Cache working.

Open up /etc/nginx/sites-enabled/default in your editor and comment out the text already there with # characters. Paste the following in. Change paths and domains to suit your site. (via)

server {
        server_name  example.com www.example.com;
        listen   80;
        error_log   /www/logs/example.com-error.log;
        access_log  /www/logs/example.com-access.log;

        location ~ \.php$ {
                include /etc/nginx/fastcgi_params;
                fastcgi_pass  127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_param  SCRIPT_FILENAME  /www/example.com/htdocs$fastcgi_script_name;
        }

        location / {
               gzip  on;
               gzip_http_version 1.0;

               gzip_vary on;

               gzip_comp_level 3;

               gzip_proxied any;

               gzip_types text/plain text/html text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

               gzip_buffers 16 8k;
               root   /www/example.com/htdocs;
               index  index.php index.html index.htm;
# if the requested file exists, return it immediately
               if (-f $request_filename) {
                       break;
               }

               set $supercache_file '';
               set $supercache_uri $request_uri;

               if ($request_method = POST) {
                       set $supercache_uri '';
               }

# Using pretty permalinks, so bypass the cache for any query string
               if ($query_string) {
                       set $supercache_uri '';
               }

               if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
                       set $supercache_uri '';
               }

# if we haven't bypassed the cache, specify our supercache file
               if ($supercache_uri ~ ^(.+)$) {
                       set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
               }

# only rewrite to the supercache file if it actually exists
               if (-f $document_root$supercache_file) {
                       rewrite ^(.*)$ $supercache_file break;
               }

# all other requests go to WordPress
               if (!-e $request_filename) {
                       rewrite . /index.php last;
               }
        }
}

I think the gzip settings above will compress cached files if necessary but Nginx can use the already gzipped Supercache files. The version of Debian I use doesn’t have gzip support compiled in, but if your system does, take a look at the gzip_static directive. Thanks sivel.

Finally, edit /etc/nginx/nginx.conf and make sure the user in the following line matches the user above:

user www-data;

I changed it to “nobody nogroup”.

Now, stop Apache and start Nginx:

/etc/init.d/apache stop; /etc/init.d/nginx start

WP Super Cache will complain about mod_rewrite missing, and you should disable mobile support.

How has it worked out? I only switched on Friday. The server did do more traffic than normal, but I put that down to the floods in Cork. Weekend traffic was perfectly normal.

Load on the site is slightly higher, probably because my anti-bot mod_rewrite rules aren’t working now. Pingdom stats for the site haven’t changed drastically and I think the Minify plugin stopped working, must debug that this week. Switching web servers is a huge task. I disabled mobile support in Supercache because I need to translate those rules to Nginx ones. A little birdie told me that he’s going to be writing a blog post on this very subject soon. Here’s hoping he’ll put fingers to keys soon.

Have you switched to Nginx? How has your switch worked out for you?

WP Super Cache 0.9.8

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:

  1. 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”.
  2. 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:

advanced-debug

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):

  1. 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.
  2. 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.

diveintomark.org-dashboard

And finally, some benchmarks, in Russian unfortunately but the pages translates well.

caching-benchmarks

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!

WP Super Cache Developer Documentation

I’ve finally found the time to write up some documentation for developers who want to work with WP Super Cache.

It’s a work in progress but should help other plugin developers who want to interact with the cache.

Suggestions and comments welcome.

PS. If you’re in Cork on November 14th, head along to BarCamp Cork III. I’ll be giving a talk, “How WP Super Cache Works”. It’ll be less technical than this but I’ll answer questions too. Check out the other sessions too.