WP Super Cache 0.9.9

Well, the new WP Super Cache is available now.

This release adds experimental object cache support. Don’t go looking for it unless you have an external object cache already. It won’t show up. I recommend using the Memcached object cache.

Some of the other major changes include more translations: Chinese (Pseric), Ukranian (Vitaly) and Japanese (Tai). The Italian and Japanese translations have since been updated but not included in 0.9.9. You can grab them from the languages directory if you don’t want to wait until the next release.

If you have WordPress Mobile Edition installed the plugin will grab the list of mobile user agents from that and warn if your .htaccess is outdated.

And, a small but significant change is that the PHP cache loader will use the static “super” cache if necessary. This might happen if your rewrite rules aren’t working properly and not serving cache files. At least your anonymous visitors will see some sort of cached file. Use the debugging system built into the plugin to determine where the cache comes from.

See the changelog for the complete list of changes.

WP Super Cache with Object Cache support

Here’s a quick post to encourage brave testers. I’m adding object cache support to WP Super Cache so you’ll be able to store your cached files in a memcached backend instead of disk.

It’s not complete but it’s running on this blog and well, you’re reading this which means it’s doing something and not breaking! If you want to give it a go grab the development version from the download page.

There are few caveats, but three spring to mind:

  • It won’t cache anything for “known” users. That is users who are logged in or leave comments. Usually a tiny minority of the visitors to any site.
  • Refreshing of the cache is very incomplete. If you leave a comment, the cache for that page may not update immediately. The cache lifetime is set to 30 seconds, and after you leave a comment you become a “known user” and see the uncached version of the page anyway.
  • When posts are updated the whole cache is invalidated.

If you don’t know what memcached is, or how to set it up then you probably don’t want to test this. If you do, use Google and find out about them. Unfortunately I don’t have time to explain how to install it.

Inspiration and some code taken from batcache, the excellent caching plugin we use on WordPress.com.

Update! I updated the Changelog in the readme.txt and I’m looking for testers. Here’s what’s new in the development version:

* Added experimental object cache support.
* Added Chinese(Traditional) translation by Pseric.
* Added FAQ on WP-Cache vs Supercache files.
* Use Supercache file if WP-Cache file not found. Useful if mod_rewrite rules are broken or not working.
* Get mobile browser list from WP Mobile Edition if found. Warn user if .htaccess out of date.
* Make sure writer lock is unlocked after writing cache files.
* Added link to developer docs in readme.
* Added Ukranian translation by Vitaly Mylo.
* Added Upgrade Notice section to readme.
* Warn if zlib compression in PHP is enabled.
* Added compression troubleshooting answer. Props Vladimir (http://blog.sjinks.pro/)
* Added Japanese translation by Tai (http://tekapo.com/)
* Updated Italian translation.

The biggest changes are the addition of the object cache and a small change to the php code that serves cached wp-cache files. If the mod_rewrite rules on your site don’t work for whatever reason the plugin will look for the Supercache file and serve that instead. An extra header is added to the served page when this happens. It’s all in the readme.txt!

WordPress MU 2.9.1.1

one dot one dot one dot one dot dot dot…. Yes, last week’s release of WordPress MU wasn’t to be the last one. This is. Really.

WordPress MU 2.9.1.1 fixes #1193 and #1195, two annoying but one liner bugs that crept into the last release.

This is also a security release fixing a bug in the installer that has existed for quite some time. If you can’t update yet, delete the file index-install.php immediately. That file is only used when you install WordPress MU for the first time so it’s not needed afterwards. Don’t ask, “I’m using version x.x.x, do I need to delete this file?” Just do it. Thanks Mad Sprat for reporting the problem.
The index-install.php in 2.9.1.1 is safe, but I’ve added a note at the end of the install recommending the file be removed. The file is not used after installation and it’s always a good idea to clean up unused scripts.

Get WordPress MU 2.9.1.1 on the download page or wait until your Dashboard upgrader finds the new release.
If you’re adventurous, download and replace the following files on your site to upgrade:

  1. index-install.php
  2. wp-admin/includes/mu.php
  3. xmlrpc.php
  4. wp-includes/version.php

Sorry Jeffro! πŸ™‚

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?