If WordPress suddenly shows "Error establishing a database connection" right after you switched PHP versions in aaPanel, your database almost certainly isn't damaged — the new PHP version is missing something the old one had, most commonly the mysqli extension. Revert the PHP version first to confirm that's really the trigger, then fix the actual cause below before switching forward again.

Symptoms

  • The site was working normally, you changed the PHP version in aaPanel's site settings, and now the front end and wp-admin both show "Error establishing a database connection."
  • The database credentials in wp-config.php haven't changed at all.
  • Switching the PHP version back to what it was before immediately fixes it.
  • Other sites on the same server, running a different PHP version, are unaffected.

Likely causes, in order of how often they actually happen

  1. The new PHP version doesn't have mysqli (or pdo_mysql) enabled. aaPanel manages extensions per PHP version — switching versions doesn't carry over which extensions were turned on, so if mysqli isn't enabled for the new version, WordPress's database class (wpdb) can't open a connection at all, and every request shows this exact error.
  2. DB_HOST relies on a socket path the new PHP version doesn't share. localhost in wp-config.php's DB_HOST typically triggers a socket-based connection rather than TCP. If the new PHP version's mysqli.default_socket (or pdo_mysql.default_socket) points to a different path than the version that was working, the connection fails even though the credentials are correct.
  3. The MySQL user's host grant doesn't match how the new PHP process connects. If the database user was created scoped to a specific host (localhost vs 127.0.0.1 vs %), and the new PHP version connects differently than the old one did, MySQL refuses the connection at the account-privilege level — which looks identical to a wrong password from WordPress's side.

Fix it: lowest-risk steps first

Step 1 — Revert the PHP version immediately

In aaPanel, go to Website → your site → Settings (or the site list's PHP version dropdown) and switch back to whatever PHP version was running before. This doesn't touch the database or any files — it only changes which PHP runtime executes the same code — so it's safe and instant.

Confirm the site loads and you can log in to wp-admin before continuing. If the error doesn't clear after reverting, the database connection problem isn't actually related to the PHP switch — check the MySQL service itself is running under Database in aaPanel instead.

Step 2 — Confirm mysqli/pdo_mysql is enabled for the new PHP version

Go to App Store → PHP for the new version → Settings (or Install extensions, depending on your aaPanel version) and check whether mysqli and pdo_mysql are toggled on. Compare this against the PHP version you just reverted to — it's common for a freshly installed PHP version in aaPanel to have a narrower default extension set.

If either is disabled, enable it and restart PHP-FPM for that version from the same settings tab. Then switch the site to the new PHP version again and retest before moving to the next step.

Step 3 — Test DB_HOST as an IP address instead of a hostname

If Step 2 didn't fix it, edit wp-config.php via aaPanel's file manager and temporarily change:

define( 'DB_HOST', 'localhost' );

to:

define( 'DB_HOST', '127.0.0.1' );

(or the reverse, if it was already 127.0.0.1). This forces a TCP connection instead of a socket connection, which sidesteps a socket-path mismatch between PHP versions entirely. Reload the site — if this fixes it, the socket path is the real underlying issue, and you can leave DB_HOST on whichever value worked.

Step 4 — Check the MySQL user's host grant in aaPanel

Go to Database in aaPanel, find the database user, and check which host it's granted for. If it's scoped narrowly (for example, only localhost) and Step 3 showed that 127.0.0.1 is what actually works for the new PHP version, update the user's host grant to match — or simply keep DB_HOST set to whichever value from Step 3 already works, since that's the lower-risk option and doesn't require touching database permissions at all.

Verify the fix

  1. Load the front end and wp-admin in a private browser window and confirm the site renders normally, with no database error.
  2. Log in to wp-admin and open a page or post to confirm reads and writes both work, not just the homepage.
  3. If you enabled WP_DEBUG_LOG while troubleshooting, check wp-content/debug.log for any remaining database-related warnings, then turn debug logging back off.

If you need to roll back

If none of the steps above resolve it, reverting to the previous PHP version in aaPanel remains fully safe at any point — it's the same non-destructive switch as Step 1, and older PHP versions stay available in aaPanel's App Store even after you've installed a newer one. If you changed DB_HOST in Step 3 and want to undo just that, restore it to its original value; this file-only edit doesn't affect the database itself.

Related fixes

FAQ

Does this error mean my WordPress database was corrupted or lost?

No. "Error establishing a database connection" is specifically about PHP being unable to reach the database — it says nothing about the data itself. In this scenario the database is untouched; only the PHP-side path to it changed when the PHP version switched.

Will reverting to the old PHP version fix this immediately?

Yes, in every case this article covers — the database connection issue is caused by something the new PHP version is missing or configured differently, not by anything that happened to the database. Reverting restores the exact runtime that was already working.

How do I check which extensions are enabled for a specific PHP version in aaPanel?

Go to App Store → PHP, find the version in question, and open its Settings or Install extensions tab — this lists every extension available for that specific PHP version along with an on/off toggle, independent of any other PHP version installed on the same server.