How I Fixed My Failed WordPress Upgrade

Today I visited my site to find that it was down…hard. I tried going into the WordPress administrator and was greeted with a message stating that my installation was out of date and that I needed to upgrade. This message was followed by a link to perform the upgrade.

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);


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:


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.


5 thoughts on “How I Fixed My Failed WordPress Upgrade

  1. Hi there – I’m glad my post helped. I should add that my blog was forced to upgrade by an exploit being run against my old WordPress.

    The end result (for me since most of my system was secure) was a file in /tmp/ with a jumbled name. Within this file was a PHP shell program. You definitely want to nuke this file.

    From what I could figure out, this file somehow gets added as a plugin to WordPress, which is loaded each time you run the page. I assume the somehow this is activated via the blog.

    The upgrade wasn’t some kind of automatic process, it’s just a flag in the wp_options table that says what version you’re running. The exploit cleared out this value, which is what forced me to upgrade.

    I would also recommend, if you find this file in your /tmp/ directory, then you should check through the rest of your file system to be on the safe side. I also removed the entry from the uploaded files list in the database (sorry – I can’t remember the table name).

    Hope some of that helps if it’s relevant!

  2. Hi there,

    I’m experiencing the same problem as you and Remy. I’ve been able to follow your guide up through changing the table names in the upgrade-functions.php file. I use custom prefixes (“b2” instead of “wp_” as I loaded WordPress over a b2 installation long ago), but I couldn’t figure out which lines I had to edit or which terms exactly I had to replace.

    Do you think you could clarify which lines should be altered? I’d greatly appreciate it, as this entry has been very helpful so far.


  3. I had a similar issue over at my blog. Seems like a lot of people are having a problem with the upgrade.php file – perhaps some of it of their own doing.

    I simply wanted to upgrade to keep my blog up to date.

    When I tried to run the upgrade.php page, it kept saying all went fine, only to ask me to upgrade again – it went in a loop. Anyways, i have described the problem in more detail on my post here

    The solution? It turned out I had the WP-Security plugin installed which was inadvertantly blanking out the WP version – and confusing the upgrade.php file. Once I got rid of the security plugin, the upgrade went fine.

    I hope that helps someone.


Comments are closed.