In the wee hours of this morning, I attempted to upgrade my blog from WordPress 1.5.2 to WordPress 2.1. In fact, I did upgrade it, but I’ve now reverted to my pre-upgrade backups (while maintaining the upgraded version in a hidden location on the server) because of several problems that I had with version 2.1. I’m going to post about those problems in the WordPress support forums, but I thought I’d mention them here too, in case anyone has similar problems and googles around to see if others have experienced the same thing. Details after the jump.

Before I list the problems that I haven’t yet been able to solve, let me mention the one I did figure out how to solve. I had the same problem mentioned here, that all comment and category counts were listed as zero (except the ones that I’d edited after the upgrade). The problem is that WP2 has a field in the “wp_posts” table called “comment_count,” and a field in the “wp_categories” table called “category_count.” This is actually a very good thing, as it obviates the need for precisely the sort of long-winded comment-counting query that was largely responsible for repeatedly crashing MySQL on my server the other day. However, rather stupidily IMHO, the upgrade process doesn’t automatically populate these fields, so all of your old posts and categories have “zero” counts until you update them. Dumb.

Luckily, this buggy post-upgrade behavior can be fixed rather simply. To solve the comment_count issue, I ran the following SQL query in phpMyAdmin:

UPDATE `wp_posts` SET `comment_count` = (SELECT COUNT(`comment_post_id`) FROM `wp_comments` WHERE `wp_posts`.`id` = `wp_comments`.`comment_post_id`)

My database has 129 categories, 14,461 posts and 107,302 comments, and the query ran almost instantaneously, so if it’s taking more than an hour, there’s something wrong with your query. Speed should not be an issue.

As for categories, that can be solved without delving into phpMyAdmin. In the WordPress interface, simply create a new post and check off every single category. Save the post. Voila, you’re done. All the categories will update their category_count field. Admittedly, it was a little annoying to manually check off 129 categories, but it was doable, and it solved the problem in one fell swoop.

Unfortunately, I haven’t been able to figure out solutions to the other problems I’m having. Commence griping… :)

First of all, my server meets the minimum requirements for WordPress 2.1: I’ve got PHP 5.0.3 and MySQL 4.1.9. And I followed the detailed upgrade instructions to the letter, including deactivating all plugins, so that’s not the issue.

Here are the problems I had — or at least, the ones I’ve noticed so far — after the upgrade was complete:

1. I can’t delete posts.

Take a look at this screenshot of my post-editing page. If you’re a WordPress user, you’ll notice that something is missing: the “Delete” link, which should be immediately to the right of “Edit.”

And it’s not just that screen. On the individual post editing screen, the “Delete this post” button is there, but when I click it, and click OK on the confirmation dialog, I get the error message: “You are not allowed to delete this post.”

This seems like some sort of issue with permissions between the MySQL database and the WordPress interface. I can delete posts in phpMyAdmin without any problem, but I can’t delete them via WordPress. Unfortunately, I have no idea how to solve it. But I suspect it’s related to…

2. I can’t create published Pages, or edit published Pages that already exist.

This seems to be the same problem that’s already been noted here, but here’s a somewhat more detailed description. In the Pages interface, there is no “Published” option under Page Status:

What it looks like:

What it should look like:

As a result, I can’t create functional Pages through the WordPress interface. I can create draft Pages and “private” Pages, but no publicly accessible ones.

In phpMyAdmin, I can convert draft/private Pages that I created in WP into published ones by changing the “post_status” field to “publish.” But then look what happens. On the Manage Pages screen, not just the “Delete” option but the “Edit” option disappear:

Before:

After:

And when I try to manually go to the “Edit” URL, I get the error message, “You are not allowed to edit this page.”

Also, regardless of whether the Page is published, a draft, or private, I can’t delete it through the WordPress interface, just like with Posts.

Does anyone have any suggestions for how to fix these problems? Has anyone else experienced any of this?

UPDATE: Here’s my WordPress support topic.

UPDATE 2: The WordPress admins appear to have “closed” that topic, presumably because they think it’s duplicative of other posts. They’re wrong, and I’ve just re-posted it with a disclaimer.

UPDATE 3: They did it again! My third attempt, here.

UPDATE 4: I complained to the “bug report” folks (since that was the only direct contect info for WordPress than I could find), and now they’ve restored my topic.

FINAL UPDATE: I eventually solved this problem. For me, the answer was to upgrade incrementally from 1.5.2 to 2.0 to 2.0.7 to 2.1, instead of going directly from 1.5.2 to 2.1. So in other words, I reverted to my pre-upgrade backups, and then upgraded three separate times: first from 1.5.2 to 2.0, then from 2.0 to 2.0.7, and finally from 2.0.7 to 2.1. It was a little tedious, but when I was done, the problem was solved.

I would recommend the same course of action for others encountering similar problems. Of course, if you’ve been using the (faulty) upgraded version for a while, you probably have posts and comments which aren’t in your backup. If so, I’d suggest renaming your ugpraded WordPress database in phpMyAdmin (e.g., from “wp” to “wp_old”) so that you can move those comments and posts from the old database to the new (properly upgraded) databse, once you’re done successfully upgrading.

On the other hand, maybe you don’t want to go through the hassle, or maybe you don’t have backups (even though WordPress’s upgrade instructions saying the most important step is making backups… they aren’t lying!). If that’s the case, you might want to try the solution suggested by elpis2000. I can’t vouch for it, because after doing the incremental upgrades, I no longer have the problem, and therefore no way of testing elpis2000’s solution. But at least one person on that support thread said it worked for him. Still, I would highly suggest backing up your database in its current state before you try elpis2000’s suggestion, just in case it makes things worse! You never know, and it’s always a good idea to make a backup before you start poking around in phpMyAdmin…

P.S. You may also want to look here, though that sounds like a somewhat different problem.

P.P.S. Here is yet another possible solution.