My solution at that time was to hard-code the table names into the script. Since that time, I’ve upgraded the same blog to a newer version and all went well.

I saw the issue again when trying to upgrade from a pre-2.0 version. Once again, the prefixes were not being read correctly. Since this was a small blog so I decided to simply install a fresh version of WordPress and import the old posts, but I ran into the same problem with a fresh installation!

This time I realized that not only were the table prefixes missing but so was the database name. I looked into it a little further and found that the instantiation of the $wpdb global variable in wp-admin/includes/upgrade.php was not working correctly.

I’m not a PHP guru, but if I understand how this is supposed to work, $wpdb is responsible for retrieving the database name and prefix from the WordPress configuration and insert that information into the script.

I passed this information to a coworker of mine who is more knowledgeable in the ways of PHP and he suggested two things. First, to use error_log() to log the possible error and second, to use print_r() to output $wpdb to the screen before the sql scripts ran. This would give me a better idea of what the problem was by displaying the contents of $wpdb.

So, I placed the following statement on line 62 of upgrade.php, after the $wpdb declaration and just above its first use:

error_log($wpdb->terms);
print_r($wpdb);

As my coworker stated, the sql was dumped onto the page, but, strangely enough everything looked fine. There were no longer any errors!

It seems as if either the error_log() or the print_r() functions actually fixed the issue. My only guess is that $wpdb was not properly instantiated and one of the functions I used to troubleshoot actually instantiated it.

Obviously, this is not a problem with all WordPress upgrades and installations. Most people have had no issues at all, but I’ve seen enough posts out there to know that I’m not alone as far as the issues go. My best guess is that it has something to do with the installation PLUS my server configuration.

I’m using PHP 5 and my coworker informed me that the upgrade was done for PHP 4. Obviously, the code has to continue to cover PHP 4. I’m just wondering if there’s a glitch involving the PHP version and possibly the PHP server configuration that’s causing issues with the upgrade code.

-rG

I ran into Dean’s Permalink Migration Plugin a while back which claimed to do all of the work for me. It looked promising and there were a lot of positive comments, but I had no luck changing my links.

Recently, I upgraded my WordPress installation and decided to give it another shot. I’m very happy I did! This time around the migration went flawlessly and took a total of 3 minutes.

All that’s required is to install the plug-in (copy it into your plugins folder), activate it, and follow Dean’s instructions:

1. goto admin panel->options->PermalinksMigration and set the old permanlink structure.
2. goto admin panel->options->Permalinks and change the permalink structure to what you want.

That’s it! It really was that easy.

The plugin will even generate a 301 Redirect when user or spider visits your site using the old permalinks, and redirect them to the new permalinks of the same post. This means you lose none of the traffic from your existing search engine entries.

-rG

After backing up my database I clicked the ominous link and waited. I didn’t have to wait too long for the upgrade failure message to appear:

WordPress database error: [Unknown column 'user_nickname' in 'field list']

So I started Googling and found I was far from alone. Great! There must be a solution out there somewhere, I thought. To my surprise, the vast majority of links led to users that had not yet resolved the issue. Luckily I came across a post on remy sharp’s b:log titled How I Fixed WordPress’ Broken Upgrade.

While Remy’s post did not solve the issue I was having, it definitely got me 50% there. The installation is looking for a column named user_nickname in the wp_users table. So, the first step toward correcting the issue was to add that column using the following sql:

alter table wp_users add column user_nickname varchar(250);

Note that, if you’re using custom table prefixes, you’ll need to change the table name so that it matches yours.

After adding the column I ran the upgrade again and the error was gone. Unfortunately, so was any other feedback or content on the page. What I ended up with at this point was a WordPress banner at the top of the page and absolutely nothing below it. Again, Remy’s solution lent a hand.

While Remy’s post directs you to edit wp-admin/upgrade-functions.php, the code has now been moved to wp-admin/includes/upgrade.php. Turns out that the reason a blank page is appearing is because there is a php error. To fix the error, it was necessary to change a line in upgrade.php (or upgrade-functions.php for older versions) from:

$all_options->{$option->option_name} = stripslashes($option->option_value);

to:

if ($option->option_name) $all_options->{$option->option_name} = stripslashes($option->option_value);

The line in question appears around line 795 (654 in upgrade_function.php).

That’s basically where Remy’s issues ended. Unfortunately I wasn’t so lucky because after running the upgrade again I was still presented with the blank screen. It was at this point that my eyes began turning green. Luckily I was able to calm myself down before my shirt began ripping and my skin turned the same color as my eyes.

I pulled up the upgrade.php file again and began scanning through it. That’s when I noticed that the table names in the SQL statements were hard-coded. While this is fine for a default installation, it’s a BIG problem for people who used custom prefixes on their tables.

If you use custom prefixes you’ll need to change all of the SQL statements to reflect your table names. I’m sure this is a variable but I didn’t have the time or inclination to go looking for it. The SQL code can be found from lines 75 through 110.

After fixing the table names I ran the upgrade again with crossed-fingers and….. it failed again. Grrrrrrr…..

This time at least there was an error to research:

Allowed memory size of 8388608 bytes exhausted

To remedy this issue I had to edit wp-admin/upgrade.php. Note that this upgrade.php file is a different file located one directory up from the upgrade.php that you just finished editing (not confusing at all, right?). I was able to fix the memory issue by adding the following line to the top of the page, just inside the opening PHP tag:

ini_set("memory_limit","12M");

I ran it again and, finally, success … kind of.

The upgrade completed with the following message:

WordPress database error: [Table 'xx_linkcategories' doesn't exist]
SELECT cat_id, cat_name FROM wprg_linkcategories
Upgrade Complete

Your WordPress database has been successfully upgraded!

Remy says to ignore the error so I’m choosing to follow his advice at this point since my site is once again up and running.

I hope this helps some of the stranded WP users out that are having the same issue and can’t find help. I also hope that the WordPress developers address this issue in an upcoming release. It seems bizarre to me that it’s existed through multiple versions.

-rG