WordPress 2.3.1 has been out for a little over 2 weeks and I finally got around to upgrading this site. In addition to the WordPress upgrade, five of the plugins I use also had minor updates available so it was a good time to update them. The update includes 22 bug fixes including tagging support for Windows Live Writer and improvements to database queries.
I upgraded my test site last weekend and did some testing during the week and didn’t find any issues. This was the first time I used a plugin called Maintenance Mode and I’ll talk about it down below. The procedure for both my test and production sites are pretty much the same. The only difference is in the timing. I update all the plugins at one time in test, but then roll them out to production one per night just in case.
1. Backup the website files (I use Transmit) and database (I use the WordPress Database Backup plugin).
2. One by one, for each plugin being upgraded: deactivate the plugin, delete the old files and copy up the new files. Reactivate the plugin and test it. Some plugins require re-entry of an API key or reset the configuration. I make a note of these when updating my test site so I don’t have to spend a lot of time checking my production site.
I do this first to make sure the plugins work under both the old and new WordPress versions. To reduce outage time I typically update plugins a few days before the full WordPress Upgrade and keep the changes to one at a time to isolate problems. For the production site this will actually be done by updating one or two plugins a night after the testing is done.
3. Download the latest WordPress release and extract the files to my local hard disk.
This update was relatively minor and it would probably have been OK to just update the changed files. Since I’m only updating one production site I decided not to go this route, but there are some people out there who have done some of the heavy lifting for this approach and packaged up the changed files. But in my case I’ll spend the extra couple of minutes and copy all the files just to be safe.
4. Configure the Maintenance Mode plugin for the expected outage (See details in the Maintenance Mode section below).
5. Deactivate all plugins except Maintenance Mode. Enable maintenance mode to block all traffic and display the splash page.
6. Carefully update the WP-Content directory with the new WordPress Files. I do not use any of the standard themes, so my concern here is to avoid deleting what I do use and the WP-Content directory is the place where there’s a mix.
7. Copy the other WordPress 2.3.1 files to my website, replacing what is already there. I do not modify any core WordPress files so replacing them is not a problem. I make sure nothing in the WP-Content directory tree gets touched during this copy.
8. Run /WP-Admin/Upgrade.php. In this case there wasn’t anything to update and it told me so. I didn’t bother to try this during the production upgrade since there was nothing to do in test.
9. Enable plugins one by one. Reconfigure those identified as needing additional configuration when re-activated.
10. Once all plugins are activated do some final testing, concentrating on pages which use plugins to generate their content.
11. Disable maintenance mode once testing is done and let people back in.
12. Test the site again, this time when not logged on as any sort of WordPress user.
WordPress Plugin: Maintenance Mode
Maintenance Mode is a plugin by Michael Woerher. When activated it puts up a landing page that says the site is down for maintenance. It also has the optional ability to return a “503 Service Unavailable” error in the HTTP header. The message displayed is also fully configurable as is the outage duration to be displayed on the page and returned in the http header for the “Retry-After <backtime>”.
The current release is version 3.2 which was released August 28, 2007.
Setup is straightforward. It installs like any other plugin. Activating the plugin does NOT block traffic. When the plugin is first activated maintenance mode is disabled. Once the plugin is activated you can find it’s configuration screen under the options menu in the WordPress admin console.
The configuration screen allow you to set the “backtime” which is used in the message and returned with the 503 status (if it’s enabled). It’s not a countdown, so someone who sees it 29 minutes into a 30 minute outage will still be told to return in 30 minutes. If this is a problem you can always edit the message to include the specific times.
You can also configure what appears in the landing page (a.k.a. splash page) title and text. HTML is supported, php is not. You can use [blogurl], [blogtitle] and [backtime] as tags that will be replaced with their appropriate values. Click the thumbnail at the beginning of this section to see what I used for my most recent update.
You can also specify specific URLs that you still want to be available. This isn’t a feature I used. All of my pages are in the WordPress DB so there wasn’t much point in keeping some available.
Finally, there’s an option to enable returning a “503 Service Unavailable” error in the http header and specify the time to return. This would prove useful to let any search engine spiders know the URLs they’re trying to reach are valid and will be back shortly.
There’s also a template tag you can use as a reminder when maintenance mode is active. The admin panels will also display a message near the top when maintenance mode is active.
This is useful since you’ll have full access to your site as an Administrator and may forget it’s active.
The Maintenance Mode plugin can be left activated all the time since the actual maintenance mode can be disabled. But I dislike leaving plugins active when they aren’t needed so I end up deactivating this one once I’ve completed maintenance.