Something I’m confused about, trying to change the database in an existing WP install, for example:
I have a local WP site (in XAMPP) working fine off a DB called database-A, however if I change, in wp-config:
define('DB_NAME', 'database-A');
To:
define('DB_NAME', 'database-B');
(just another WP DB)
I get:
Error establishing a database connection
But if I export database-A into a .sql file, and empty out database-B and then import the database-A .sql file into database-B, the site works.
So what’s validating the data to the WP install to make it work, and why won’t database-B just work with the WP install?
Things I’ve tried:
- Changing the Authentication Unique Keys and Salts in wp-config.php
- Changing instances of the site host name in the database
- Deleting cookies
1 Answer
Reasons this might happen:
- When WP checks the tables exist and they don’t
- If the DB connection fails
- The database is unreachable
- A
DESCRIBE
query on the tables fails, be it permissions or access based - If there is an error recorded in the wpdb object while setting up initial variables in
wp_set_wpdb_vars
- When
ms_load_current_site_and_network
returnsfalse
- if
get_networks
returnsfalse
, so there is no current network - When
if ( empty( $current_site ) ) {
is true, indicating it could not figure out the current site - When
} elseif ( 0 === strcasecmp( $current_site->domain, $domain ) ) {
is true
- if
So, you can’t just swap out 1 multisite database for another, because:
- They need the same table prefixes, salts, etc
- All the sites in the sites tables need to be present or it won’t be able to find the current site
- It needs to be able to find the current network ( all multi-sites are also multi-networks, but there’s no network UI )
- Both databases need appropriate authentication details
Right now, it’s near impossible to tell from your question which one is were you tripped up, and it’s possible there are more places. If you manage to get it working though, my first recommendation would be to stop doing it.
It’s a great way to gain technical debt, complicate things, make them more fragile, and stop standard deployment and migration tools from working properly.
I have a suspicion that your database names might be called production
and staging
in which case, this is not the appropriate path to take to solve switching between the two