July 27th, 2008Ironing Out A WordPress 2.6 Upgrade
Despite my seemingly endless criticisms of the platform, WordPress is still one of the easiest and most versatile platforms available for companies and individuals who want to host their own website. That said, one criticism that many people have had over the last few years involves the number of hoops a person must go through when upgrading to the next release. While the developers at Automattic have certainly done their part to simplify the process, many people opt to use their older, and still reliable, releases. But what can a person do when they attack an upgrade using a “Scorched Earth” methodology?
I recently faced a number of complications after bringing a heavily modified 2.1 WordPress installation up to the most current 2.6 but, after a 48-hour “time out”, I managed to approach the problem in a rational fashion to solve some of the frustrations I encountered. These issues ranged from something as minor as having my Akismet spam counter set to zero, to a major issue regarding the uploading and insertion of images.
Hopefully this quick little ‘How To’ will help others experiencing the same hiccups.
Starting From Scratch (Scorched Earth)
Before getting too far into this, I should tell you that many of these issues had occurred because I decided to create a new installation of WordPress with a fresh database, then migrate the data over. I’ve done this on a few occasions in the past without so much as a beep, but it was quite a bit different when I decided to upgrade my personal blog.
The reason I had approached the upgrade with a blank database was to accomplish two very important goals: switching from a PHP 4.2 database to a 5.0, and to prevent any unreversable changes that would have occurred had I updated my WordPress database.
By going this route, I needed to first export my existing WordPress data as an XML file. This is done via the Manage / Export screen and takes about 3 minutes. I had 625 posts and 1,492 comments to export, so it wasn’t too much data … about 8 megabytes.
If you plan on doing the same, please keep in mind that the export screen only covers posts, pages, categories and comments. If your database carries any other information you’d like to keep, that will need to be done manually via PHPmyAdmin, Query Browser, or your MySQL tool of choice.
All in all, building a new WordPress blog with a fresh database and importing the existing data was pretty quick. It was all set and running in under 5 minutes.
The first issue I had uncovered was the fact that I couldn’t upload pictures when writing posts. Regardless of which image uploader I used, nothing wanted to work. No error message was given, and few people had an idea as to what might be causing it. Luckily, I stumbled upon this article on the WordPress forums where some others were having a similar problem. In their case, though, they were putting media uploads in an alternate directory … most commonly called /images/. I was using the default /wp-content/uploads/ directory, though? So would their reported fix work for me as well?
Oddly enough, yes.
The solution is to specify the full path of your uploads directory. Although this should not be necessary for default folders, my image problem quickly became a thing of the past after setting the option.
Where the Heck Is My RSS?
The next infuriating issue I had noticed had to do with my RSS feeds, or rather, the lack of. This mess up was of my own doing, though.
It seems that FeedBurner doesn’t like it when feeds are longer than 512 KB. I had made the foolish mistake of increasing my feed to show the last 25 posts but, thanks to the length of the articles, this was far more info than FB was willing to take. After bringing this back down to the default of 10, the problem disappeared.
Akismet Shows Zero Spam Captured
If you love numbers, seeing something reset to zero can be a little disheartening. This is something that will only happen if you’re starting with a blank database but, luckily, this can be corrected with a simple SQL query. Simply run the following code against your WordPress database:
UPDATE {Database Name} SET `option_value` = ‘{Spam Count}‘ WHERE `wp_options`.`blog_id` =0 AND CONVERT( `wp_options`.`option_name` USING utf8 ) = ‘akismet_spam_count’ LIMIT 1 ;
Replace the database name with your own, and the spam count to whatever you’d like. Be sure to set your spam count to a number between 0 and 4,200,000,000 (give or take) to avoid counting issues.
Not Done, Yet
There are a few issues that remain, but I think these will be resolved pretty soon. One that bothers me quite a bit is the fact that I couldn’t update my FireStats installation. I haven’t yet invested too much time into the matter but, without FireStats, I’m now mostly dependent on the less accurate statistics provided by Google Analytics. On top of this, I’m no longer able to log in to the admin screens with Opera Mobile. I hope to find a solution to this relatively soon, but might not need one if I can update Embink to display this data quickly enough.
Have you upgraded to 2.6? Were there any complications?
















































I’m glad you’re getting things working, Jason. I bet in time you’ll find a simple solution to that Opera Mobile login problem, too.
Here’s a question for you. You said your database, at 8MB, doesn’t contain too much data. At what point would you consider it bloated? My JapanSoc database is already over 20MB. Should I be concerned?
Bloat is an interesting thing, in that it’s different for everybody. However, considering how I have just under half-a-million words in my pages and posts and almost a hundred thousand words in my comments, 8 MB is pretty reasonable for an XML-based export file. The current (live) database with all of the other data (Stats, plugin tables, etc.) sits at just over 56 MB uncompressed.
This said, I think JapanSoc’s database is quite small considering how much data is actually there. I wouldn’t worry about the size of the database just yet, though. These things need to be several hundred megabytes before you need to worry about a weekly or daily maintenance schedule.
Let me know if you have any questions about databases, though. I’d love to talk shop once again
Will do, and thanks for putting my mind at ease regarding database sizes.
When exporting and importing the data from an older version of wp to a new one. Does wp automatically take the new db structure into account. Specifically is the new db structure for categories and tags something I need to be worrying about.
Thanks,
Brian
WordPress had no issues importing my existing data from 2.1 into the new database structures. Pages, Posts, Comments and Categories all appeared as they should. Because tags were not used in 2.1, they were all left blank after the update. That said, there should be no issues importing tags from previous versions. If you had used a seperate plugin for tagging (Ultimate Tag Warrior, for example), there are tools available that will let you import these into the new 2.6 structure.
Hope this helps
Do posts have to be moderated before being published?
If by Posts you mean Comments, then yes. I receive quite a bit of spam on this site, and Akismet only captures so much. Because of this, readers are required to have one approved comment before others are automatically displayed. Now that you have an approved comment, well … two, all future comments will appear without my interference
Thanks for stopping by.
Jason,
This blog post helped me out immensely during a recent Wordpress migration.
Thanks!
You’re very welcome, Darren. Let me know if there’s anything else I can help you with
Oh, Thanks! Really amazing. keep working!
Interesting post. I haven’t upgraded my blog DailyJ to 2.6.2 yet (mainly due to laziness) but I had to upgrade several other sites.
Uploading of media/images in 2.5 and 2.6 has been a gamble for me too. Sometimes it works out of the box sometimes it doesn’t. I don’t know why they made the flash uploader, it is nothing but trouble. There is a wordpress plugin that disables it though and may solve the problem you mentioned. http://wordpress.org/extend/plugins/no-flash-uploader/
Image handling has been one of the stumbling blocks with WordPress upgrades and, after updating over a dozen sites several times over the course of this past year, I’ve seen more than my fair share of doozy’s. What’s interesting, though, is that no two problems are alike. What works with Site A on Server A will not always fix the same problem with Site B on the very same server.
Oh well … perhaps I should go back to updating the WordPress core myself whenever a security flaw is found, much like I did for WordPress 2.1. Although this would mean diverging from the “supported code”, it would be superior to messing up a dozen sites and handling an ungodly number of support emails and phone calls
*Sigh* seems like nothing in life is easy, even the versatile wordpress.
Best of luck with whatever you decide to do.
And there is what some alternative?
There are alternatives, but none are quite as widely accepted as WordPress. Perhaps in another few years we’ll see something new, but I won’t hold my breath
WordPress 2.7 is almost ready for release. Hopefully we won’t see yet another repeat of the seemingly constant growing pains that seem to be associated with the “major upgrades”