WordPress Install/Upgrade Issues Linger in 2.6.2

Back in March I wrote a post detailing the issues I had upgrading to an earlier release of WordPress 2. One of the issues was that I use custom table prefixes and they weren’t being read correctly by the upgrade script.

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