Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
For that db user ID, have you confirmed that it has been granted all privileges?
http://codex.wordpress.org/Installing_WordPress#Using_the_MySQL_Client
mysql> GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname"
-> IDENTIFIED BY "password";
Yes, I have done this, and just tested it again. No change “Error establishing a database connection” is still showing on page reload.
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
That’s bizarre. You do have backup copies of your files and database? If not please make them now.
http://codex.wordpress.org/WordPress_Backups
http://codex.wordpress.org/Backing_Up_Your_Database
http://codex.wordpress.org/Restoring_Your_Database_From_Backup
Once that’s done (no, really, make those backups), if you’re up to it try to create a new WordPress installation with the same database and credentials.
Here’s the fun part: rename wp-config.php to wp-config-SAVE.php and .htaccess to .htaccess-SAVE. Just rename then, don’t delete them.
Copy wp-config-sample.php to wp-config.php and fill in the database, user/password, database server, etc.
BUT use a brand new table prefix. Switch it from
$table_prefix = 'wp_';
to
$table_prefix = 'test1_';
Use any table prefix that does not already exist.
That will leave the old tables and data alone and intact, but will let you see if a plain Jane fresh install of WordPress can work on your server.
Then visit your blog at http://your-blog-url/wp-admin/install.php and see if that can be made up and running.
If that works, then something may have gone really bizarre with your old wp-config.php.
If that doesn’t work, delete the new wp-config.php and .htaccess files, copy back the original -SAVE copies and you’ll be right where you were before.
This was a good suggestion, and has got me a little further forward. In this case, I am attempting to recover from a backup anyway, so I already have the dump.
I’ve managed to create a new multi-set blog again the same database with the same settings. I did have an issue with my .htaccess — I had a line in there which was supposed to prevent access to my .svn directories (I normally install WP with a tagged version from svn).
But I now this working correctly. The symptoms have changed somewhat. With the new database (on a test prefix) the wordpress installation appears to be working. With my restored database, I get an infinite redirect — as you can see from this wget trace below.
–2012-01-26 11:09:47– http://thing.org/wp-signup.php?new=thing.org
Reusing existing connection to thing.org:80.
HTTP request sent, awaiting response… 302 Found
Location: http://thing.org/wp-signup.php?new=thing.org [following]
I’ve changed the domain name from the real one.
Very confusing. I *think* that the redirect is happening inside wordpress rather than at the .htaccess level. So, my restore is not working it appears.
Now, I do have my old .htaccess and wp-config.php but I am trying not to restore these also for two reasons. Firstly, the site was originally hosted on WP-MU and I think that there is some cruft left over. So a clean installation seemed to be a sensible thing. And, second, I am doing this restore (partly) because we got hacked through the timthumb exploit. I’m somewhat worried the database is hosed, although we have checked it as well as we can.
Phil
It turns out that I was correct. After a substantial amount of debugging through the entire wordpress load process that the redirect problem was caused by my attempt to test the database. I had moved the
$table_prefix = “test_”;
back to
$table_prefix = “wp”;
missing the underscore. Rather perversely, this causes an infinite redirect when wp_config.php is set up for a multi-user site (because wordpress can’t find the blog ID, so it redirects to the main site, I think, which it can’t find the blog ID off either and so on).
Fixing this error got me back to the “Error database connection” issue. So I have no debugged this also. WordPress is, in fact, establishing a database just fine — so the error message is not that useful or accurate. The error comes when WordPress attempts to find whether the current blog is “installed”. It is looking in wp_options for this, and unfortunately fails because I don’t have wp_options — WordPress gives a misleading database connection error when it finds that wp_options does not exist but several other wordpress tables do.
The reason that wp_options doesn’t exist is because I am trying to restore a multisite blog, so it should be looking in wp_1_options, as this is a per blog table.
I haven’t worked out yet why this is happening; I am guessing I have some error in my multisite config looks fine to me.
So, back to the start, debugging the wordpress load process again.
BTW, I realise that this looks a bit mad and that I am talking to myself. I just post here in case anyone finds it useful in the dim future.
Phil
A bit more picking and forum searching, and I think I have discovered the problem.
It appears that between WPMU and WP3 there has been a change of database format. For WPMU, the first blog was stored in the wp_1_* tables, second in wp_2_* and so on. However for WP3, the first blog is stored in wp_*. Now, for a blog that has been migrated, WordPress does the right thing and copes; I am not sure why, but something in my old wp-config tells it that this used to be a wpmu database.
Now in my case, I have taken an old wpmu database and done a restore into a totally fresh wordpress. End result — “Error Database connection”. Not a good error message, I fear, and I shall send in a bug report.
I now have all my admin pages back, all looking well, along with my content. Plugins and themes to go and I should be back to normality.
Phil
