I didn’t think it was going to happen … but I’ve finally upgraded to the latest version of WordPress. It wasn’t easy, and I’ve been swearing like an Irishman as issue after issue was uncovered when I started to bring all of my data over. What was the root cause of all my problems? It seems I has having some severe troubles with my database.

Yesterday I had gone through the upgrade process a total of four times, each time with varying degrees of success. Late last night, I managed to get most of the site operational after several hours of downtime, but I had lost all my categories, some of my Japanese characters, and a good portion of my hair. This morning, I decided to do something I should have done in the first place: upgrade my dev environment for the new version with my live data, copy the stuff right over, update where necessary, then just push the whole thing over the existing website.

Dev Loves 2.6

I’m usually testing the new releases of various software packages in enclosed environments, and seeing just how easy it will be to upgrade some of the sites that I’m responsible for. In 95% of all cases, upgrades with backup data go flawlessly. The only time I’ve run into some major issues is when I’m trying to upgrade something that needs very particular settings in the php.ini file (but I’ve recently discovered how to get around that on my server). For this reason, I’ve often reported that an updated version of some software is great, and that there were no issues when testing the updates while in the Dev environment. But, when it comes time to actually make the change, my site is down for too long, Google takes me out of their SERPs, and I spend the better part of a weekend in a foul mood as the things I want to be doing just aren’t getting done.

Fun?  Wow!

As I had mentioned earlier, the main problem appears to have involved the database itself.  I had been using a heavily modified version of WordPress 2.1 and, aside from some problems with the newly released plugins, it was working great.  I had modified WordPress 2.1 whenever a new security release would be made available for the various versions.  If 2.1 was affected by the same problem (which I would find out through various forums or sheer dumb luck), then I would update the code accordingly.  Although the 2.1.x line is supposed to receive security patches regularly, this does not seem to be a high priority for the Automattic team.  Considering how many other projects they’ve been working on, I can certainly understand the issue.  So my problem stemmed from some of the stuff I had done way back in June of last year, and it’s carried forward without many problems ever since.

So How Did I Fix It?

When a database goes awry, it’s a terrible time for anyone.  Luckily, I have lots of database tools to work with and lots of backups to restore and play with.  For me, the solution that worked the best is often lovingly referred to as “Scorched Earth.”  This essentially involves killing the database and starting from scratch.

And that’s just what I did.

Starting with a completely empty database, I installed 2.6 and then, using WordPress’ Import Utility, I imported all of my posts, pages, comments and categories to the new database.  This is a great way to quickly restore data to a new database, and it keeps any extra characters that you might be using intact.  From here, I needed to pull in all the other database tables that were used by various plugins.  This has always been the hardest part, but it’s made a trivial task with MySQL Query Browser.

Of all the plugins, the one I had the most trouble with was FireStats.  I love this application, and I had been using a really old version (with database version 6 — the current release uses 14) as it had worked perfectly for my needs.  That said, after updating the site, I wanted to have an updated stats package, too.  I have done this several times for other people’s sites without hassle, so it shouldn’t have been too much trouble for me.  Well … that was the initial idea.

After three failed attempts to upgrade my existing data, I decided to throw caution to the wind and create a seperate database just for FireStats to use.  This was incredibly simple and, after the system had created all the necessary tables, I simply forced my existing data into the new tables.  This allowed me to keep my two years of data while accepting new.

Lucky Day!

Once all of this was complete, I shut off all the plugins, re-directed the database (done in the settings), deleted the live website, moved the dev data over, and logged in to the admin screens.  Done and done.

Final Result?

It seems that everything is now working just as I would expect … except for one big area: I can’t insert images.

Once again, I can’t put images in my posts.  This is incredibly frustrating as I use at least one image in every post.  I can upload.  I can specify attributes.  But, when I go to put that image in the post, I don’t get an image.  Instead, I get an ugly depressed box that tells me it should be seeing an image.  What gives?

That said, I don’t have the time nor the energy to mess about with this right now.  I’ll take a look at correcting the matter tomorrow night while battling insomnia.

Has anyone else had problems with images in WordPress 2.6?  I’ve tried both the flash and non-flash versions to see if it was a browser issue, and I’ve tried both Opera and FireFox.  No luck for either :???: