Without a doubt, one of the most popular requests we receive from our clients is to help them upgrade their WordPress installations to new versions when they come out. Despite typically being a rather painless operation, we always plan for the worst, and always do a full MySQL database backup prior to attempting the upgrade. Our tool of choice for that operation is the WP-DB-Backup plugin, which basically mimics what mysqldump does from the command line. From the resulting download, you can completely restore the data within your MySQL database.

Once we do a MySQL backup, we then upload the new WordPress files to our client’s server. Once that’s done, a simple navigation to http://www.clienthostname.com/wp-admin/ will bring up a WordPress dialog indicating that the database needs to be upgraded. Once you click “Upgrade”, you’re typically done, and can start rockin’ it out using the new version.

While that entire procedure usually goes rather smoothly, sometimes there are a few glitches. If you notice a problem, the first thing I usually try to do is to recopy the files over to the server. I’ve found that sometimes various files don’t properly copy over on some servers, especially during a really long transfer. In those scenarios, recopying the new WordPress files has resolved the problem.

The second thing I usually do is to systematically deactivate plugins to see if the problem goes away. Usually you’ll find a certain plugin that doesn’t seem to work with the new version, and you can simply leave it deactivated and wait for a new version to come out. If that doesn’t solve your problem, you’re officially into the realm of “uh oh”.

Since you have your trusty MySQL backup, you can always restore the old version and forget about upgrading until a later time. While that’s sort of like hanging your head in defeat, it’s a better option than not having a working site at all. I’ll not detail the procedure involved in that, as it’s rather complicated (and better left for it’s own blog entry).

The last thing you should check is the actual state of your database. One time I had a WordPress upgrade go completely smoothly, except that everything on the website suddenly started returning 404 errors (page not found). Navigating through the WordPress administration panel showed a large number of posts (1800 or so), but none of the post data was showing up on any pages. I logged into my host’s database area and loaded up phpmysqladmin. Since the posts were the ones that seemed to have the problem, I clicked on the “wp_posts” table to see if I could see any data. Sure enough, I was greeted with the following error message:

“Table wp_posts has crashed and must be repaired.”

The good news is I found something wrong. The bad news is the entire database table for the posts and pages seemed to be borked. Thankfully, there’s usually an easy way to fix that error. Click the SQL tab on the top (the area where you can manually enter a query), and type “REPAIR TABLE wp_posts”. The REPAIR TABLE command tells MySQL to attempt to restore a table to its working state, either by rebuilding all the index files, or deciphering what went wrong. In my case, MySQL chewed away for 5 seconds or so and finally output the message “OK”.

At that point, WordPress was up and running again. So while upgrading WordPress is typically painless, you have to be prepared for times when it doesn’t go so smoothly. Even though making a full backup is a pain, it is well worth the time it takes if an upgrade fails and you’re suddenly looking at the prospect of losing years worth of entries.