1

// Be sure to read the updates at the bottom

I have a large multisite installation hosted on XAMPP on an XP 2003 server and am trying to move it from XAMPP/Apache to a new Windows 2008 server with IIS7.

I can successfully get fresh installs of WP up and running and can get multisite working perfectly. When I import my old WPMS MySQL database and change the DB_NAME in my wp-config.php file to have the old WPMS database instead of the new WPMS database, I'm hit with "Error establishing database connection"

Here are my wp-config.php settings:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'migrated_DB_2012');

/** MySQL database username */
define('DB_USER', 'wpms_user_2012');

/** MySQL database password */
define('DB_PASSWORD', 'wpms_password');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

I've double checked the username & password and even changed them several times to make sure they matched up. I've tried localhost, 127.0.0.1, and the IP address of my server itself for the DB_NAME. Nothing.


/* UPDATE */

I've successfully connected to the database finally!

Visiting the front page of the domain (http://domain.com) gave me the Error establishing database connection message, but trying to visit the dashboard/admin area (http://domain.com/wp-admin) helped me see the problem. In my many DB/user name changes, I neglected to give full permissions to wpms_user_2012 on migrated_DB_2012. D'OH!

// New Problem

I still get the database error when visiting the front page, but now when I visit /wp-admin, I see the following:

One or more database tables are unavailable. The database may need to be repaired.

When I follow the "repair" link, it walks me through the auto-repair sequence, but since this is a multisite installation, it skips over a few tables and tells me the following tables don't exist:

  • wp_posts
  • wp_comments
  • wp_links
  • wp_options
  • wp_postmeta
  • wp_terms
  • wp_term_taxonomy
  • wp_term_relationships
  • wp_commentmeta

Only, these tables do exist, but they exist as: wp_1_posts, wp_1_comments, etc.

What should the next steps be to get my migrated DB to work properly?


/* Let me explain a little more */

For this installation, I started from scratch with a fresh install of WP, set it up with a network and then copied the old /blogs.dir over to the new wp-content/.

(Reasoning for fresh install: I believe my old site had been hacked and I wanted to prevent any compromised core files from being transferred over to the new server.)

Next, I imported my old database (migrated_WPMS_database) into MySQL via phpMyAdmin, gave the appropriate privileges to the wpms_user and set up wp-config.php with the proper database/user/password information.

I ran the WP repair and you can see my // Update for the results. Basically, it was telling me that the main site's tables weren't there: I've read that the "repair" feature doesn't work well with WPMS because it looks for wp_[tableNames] instead of wp_1_[tableNames]. Am I mistaken?

After this, I even went through phpMyAdmin and ran it's built in "repair", also.

I can still connect successfully to the fresh install's database (test_database) if I change wp-config.php accordingly. So, it is seeing that it is a network and it is able to connect to the database server successfully, too.

Based on the WP Repair results, it seems WP is still looking for wp_[tableNames] instead of wp_1_[tableNames], is that right? Why would it do this? There's got to be something I'm missing inside the migrated database's tables or something, because of the message I receive when trying to access wp-admin:

One or more database tables are unavailable. The database may need to be repaired.

If it helps, my OLD site was set up as WPMU back before the merge, so the OLD wp-config.php is set up slightly different, and if I use it instead of the newer 3.3 wp-config.php, my front-end becomes a blank screen and I'm able to get to the wp-login screen ... but it just puts me into a redirect loop back to the login page.

5
  • Are you sure you migrated everything properly? Including wp-config.php? This sounds like a case of WP thinking it's still a single-site installation.
    – EAMann
    Apr 5, 2012 at 17:32
  • My old site had some hacked files in there somewhere. So I was trying to prevent this bad code from coming over to the new server. I created a fresh install, set it up as a network, then moved the old site's wp-contents folder to the new server and imported the old database. So, there was a new wp-config file created. I was successfully connecting to the database, but it was telling me that there some of the tables weren't there: I've read that the "repair" feature doesn't work well with WPMS because it looks for the wp_[tableNames] instead of wp_1_[tableNames]. Am I mistaken?
    – joshmax
    Apr 5, 2012 at 18:41
  • @EAMann, I added more explanation to my question.
    – joshmax
    Apr 5, 2012 at 20:11
  • So the old site was the exact same version as the new site? "my OLD site was set up as WPMU back before the merge" doesn't make this very clear.
    – EAMann
    Apr 5, 2012 at 20:16
  • @EAMann, yes, the WP versions are the same (3.3). I'm just saying that the files look slightly different since I started with MU before 3.0. Here are the wp-config files: Old WPMU 3.3 based wp-config.php & New WPMS 3.3 based wp-config.php. They're both WPMS now, but I'm using MU & MS to differentiate between the two. Still basically the same, just a few things have changed. Like, the old file used define('VHOST', 'no'); to say to use subdirectories & not subdomains. New version uses define( 'SUBDOMAIN_INSTALL', false );.
    – joshmax
    Apr 5, 2012 at 20:50

1 Answer 1

0

I worked through this problem myself with the help of a forum mod on wordpress.org. You can see the full forum post here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.