Back in December I did a blog post about Updating to WordPress 2.3.1. I noted in that post that I waited a long time to do the update because I knew it would be a somewhat painful process. I probably spent an hour getting the stage set (backing things up including the database), and reading and re-reading the instructions.

I then completed the actual update in about 2 hours. Not horrible, but still not something you do on a whim. Ironically, 2.3.2 came out within a week or so of my doing the update. But, I was not in any hurry to do it again. So I waited.

It was with some pain that I saw that 2.5.1 was available, and saw the dreaded words indicating that it included an important security update. That’s a good way to get my attention enough to contemplate investing a few hours in something, so I decided to go through it all again.

Given the expected downtime, I set aside a few hours of my Saturday to get this done. Saturday afternoon I went to the Upgrading WordPress page on the WordPress site. That’s when I saw it:

What? Update in about 2 minutes? You are so full of … What the heck I decided, let’s give it a try. So I clicked on the link to go get the WordPress Automatic Update plugin. I then tried it out.

Well it definitely took longer than 2 minutes, but I was actually done in about 10 minutes. When I was done with it, I sat there a bit stunned. I had geared up for a major grueling task, and it was over in no time.

Note that the plugin does backup your entire blog and your database right at the beginning. So if anything goes wrong you should be able to restore things relatively easily.

The only odd thing in the plugin is that when I got to the last screen where it was supposed to enable my pluging again, I got an error message. I ended up having to manually reneable the plugins (which is easy of course). I then spent some time checking out the blog to make sure that everything was ok, which it was.

All in all though, this is one phenomenal tool. Don’t even think about doing an update the old way any more, unless you have reason to believe that you have done some custom things to your blog that the tool won’t be able to deal with.

For the longest time I let my blog remain on the 2.02 version of WordPress. One of the reasons that this was the case is that upgrading WordPress used to feel like a potential nightmare. While I am moderately technical, I am no web server geek by any means, and in the past there were steps in the process that felt like they would require me to be one to make sure everything went smoothly.

However, when I checked out the procedure for upgrading to WordPress 2.3.1, it suddenly seemed quite a bit easier to take on. So two weekends ago I took the leap and did it. I do have to say that the Basic WordPress Upgrade Instructions seemed inadequate.

I went straight to the Extended WordPress Upgrade Instructions. Even when I got there, I skipped the overview provided and went straight to the detailed instructions. This is a must do, because it’s only here that you get all the details of everything you need to do. For example, it is only here that we see that there are certain files from the old version that you do not want to delete.

With the detailed instructions everything was fairly straight forward. Plan on allocating a solid continuous 2 hours to do the upgrade, and more if you have done customizations of your theme files (because you will need to redo these). Also, be aware that your blog will be down during this process. Users will not see your content.

As a result, you should plan to do this upgrade at a very low traffic time for your blog. You may also want to provide a temporary web page to replace your blog during the upgrade to let people know that it is going through maintenance. In addition, if you are not technically very adept, make sure you have help available in short order if something goes wrong (I did).

Here is a summary of how it went:

First steps

1. The first thing I needed to do was back up the SQL database file. This is where all the blog posts for your blog live, so you want to make sure you have this backed up. You should, in fact, back this up regularly any way.

If you do not know how to executve this step, hold off on the upgrade until you have found someone who will do it for you. In my case, I leaned on the expertise of my partner, John Biundo, to take care of the backup (he has also set it up so the STC blog gets backed up on a weekly basis automatically.

2. The next step was to back up all of the files in the blog directory on my server. These are all the WordPress 2.02 files. I copied them to a separate directory on my PC. This was a very simple step. One drag and drop in my FTP client, and I was done.

3. This is the step is what the WordPress instruction calls “the most important step in the upgrade process!”. Personally speaking, I looked at the files, they were on my hard drive, end of story. In any event, don’t be too alarmed by this step in the process. Yes – it is important. It’s there to save your bacon if something else goes wrong during the upgrade process.

However, if you are patient, and take your time at this, you should be in good shape. Nonetheless, do not skip the backup setps, or the verification step (ideally verify that you can open the files).

Getting Down To It

4. Hext step is to deactivate all of your plugins. The reason for this is that some of the plugins may conflict with the upgrade process. Easy to do – just go to the Plugins menu and deactivate them one at a time.

5. Next, I donwloaded the WordPress Upgrade Package from the WordPress site onto my hard drive. I put this in a different directory from the one where I put the backed up version. One folder I called WordPress 2.0.2 (where I put the old files) and the WordPress Upgrade Package I put into a folder called WordPress 2.3.1.

In theory, you can go straight to your web server with the files, and unzip them there, but I knew I was going to have to customize the theme files any way, so I wanted to have all the files on my hard drive as well.

6. The next step was to delete the old WordPress files from our web server. Be careful! This is one of the areas where it’s only in the detailed instructions that it explains that there are files that you don’t want to delete. Take your time on this step, and make sure you know exactly what to delete and what not to delete. Failure to do this accurately will cause more work for you later.

I chose to interpret the instructions from WordPress on this point very literally. It may feel silly to not delete a file that you know is going to be overwritten any way, but the more important part of this is that there are files that are not going to be overwritten, and following the WordPress instructions precisely does work (it worked for me in any case).

I used my FTP client to handle the deletions and this took place without any problems.

7. Upload the new files! You are almost through the basic part of this process. The detailed instructions tell you that you must upload everything but the new wp-content folder first, and then you can upload wp-content after everything else is up first. Note that I did not do that quite so precisely as all that – but I would not ignore the advice if I were doing this again.

8. Next up is to run the upgrade script. All you need to do here is open your web browser and open up http://www.yourdomain.com/Your-Wordpress-Folder/wp-admin/upgrade.php. If you have WordPress installed at the root of your site (i.e. the blog is your site), then you can simply invoke http://www.yourdomain.com/wp-admin/upgrade.php. This part of the process took me no more than a few minutes.

9. According to WordPress, the next step is to update your Permalinks and .htaccess file. You start by checking Options->Permalinks to see if there is anything you need to adjust (for example, if you overwrote the config file when you uploaded your files, you may need to set these options again).

In addition, if there is any reason why you would need to update your .htaccess file, this is the time to do it. In my case this was not necessary.

Approaching Paydirt

10. Now here is a step I added to the process – go check your blog and make sure it’s breathing. The plugins will all be deactivated, and any customizations you did to your theme will be missing, but it should be there. Just make sure before you go any further.

11. Go get the latest versions of your plugins. I first downloaded these to the plugins folder in my WordPress 2.3.1 folder on my hard drive, so I’d have them there. Then I uploaded them to the correspnding folder on my web server.

12. Reactivate each of your plugins and make sure that they work. I did this one at a time in sequence. I did have one of my plugins that did not seem to work quite right, but I can live without it, so I deactivated it and moved on.

13. Redo any code customizations you have done to your theme. I use the default theme, and whenever I edit a file in the theme, I save the original file to a different file name (e.g. sidebar.php.original), and then clearly mark my changes with comments, such as “<!– Code Added by Eric –>. Since I did this when I customized the 2.0.2 version this made this stage much easier.

I simply went to the 2.0.2 version of each edited file, found the customizations, and ported them manually into the new (2.3.1) version of the file. Once I had completed each change, I uploaded it, and then tested it out and made sure it was working before I made the next change.

Take it for a Real Test Drive!

14. Once all your customizations to the code (if you had any) are back in, you should be in good shape. Check out your blog home page, some permalink pages, category pages, date archives, and any special pages that you have. Make sure they look like they are all in good order. If anything does not look right, the chances are that one of your code customizations was not done quite correctly.

Summary

Do plan on this taking at least 2 hours, and more if you have code customizations to do. Be very meticulous about it, and make sure you take each step in the same order as described in the WordPress instructions.

Upgrading is worthwhile. For example, there are plugins I wanted to install (such as the Yahoo Shortcuts for WordPress Plugin that will not run on 2.02.

In addition, one of the major reasons is to reduce your vulnerability to hackers. Hackers are a fact of life on the web today, and software providers, such as WordPress, are frequently releasing updates that fix security holes. This is a major reason for staying current, or near current.

It was a very scary moment. I was looking at the home page of my blog, and there was nothing but a WordPress database error of some sort. The irony of it was that I had just gone in, for the first time, to try and protect the history of the blog with the first backup I have ever done of it. And the process had somehow blown it away. Basically, I had gone through the following steps:

1. Ran PhpMyAdmin, the admin tool for the SQL database
2. Selected Export
3. Checked the Gzipped box at the bottom
4. Clicked on “Go”

Supposedly, this procedure is 100% safe. However, it seems that there is a microscopic chance that the database might be in the middle of an update while it is being written out (so I am told). This seems so 1950′s to me. When I was first learning computer science back in the late 1970′s, the idea of preventing access by others to a computer asset when you are using it was already old.

Be that as it may, matters were made worse by the calls to my hosting company, iPowerWeb. They told me that the Export operation in fact “emptied” the database. While this did not make sense to me, I have no experience at all with SQL, so it added to the fear of the situation (by the way, it’s not true either)

So I got their help to do an import of the backup file I had created. However, at my request, they did not overwrite the original database file, and uploaded it as a new file. However, when they were done, I was still left with the task of getting WordPress to use the new database as opposed to the old one.

I was not willing to do this on my own, as I simply did not want to make a mistake at this point. So I called back the tech support team, and found out that everyone there competent enough to address the problem had gone home! So I was basically flushed for the night, at least as far as they were concerned.

Fortunately, I got one of the people who works with me that has a good background in SQL on the phone. In short order we figured out that the original database still had all the data in it. A little bit later, we decided to run a repair operation on the database, which is easy to do right from the main Admin screen.

Bingo! We were back up and running. It had been a very upsetting sequence of events.

Nonetheless, in its own odd way, it underscored the value of backing up. Weird stuff still happens to your data from time to time. I am not naive about this stuff, so it’s not really black magic to me.

Most likely what happened is that some other application was trying to update the data right at the time I was backing it up, and the simultaneous operations corrupted it. It’s a shame, really, because this can only result from sloppy programming, as it’s 100% preventable. However, this is why we backup. Humans are involved in designing and implementing the programs we use, and they are prone to error.