“Error establishing a database connection” appears as the only message on every page. The site is gone for visitors. The dashboard at /wp-admin shows the same error and locks out all logins. WordPress runs on two layers: the PHP application and the MySQL database. When PHP cannot reach MySQL, every page request returns this error in plain text on a white screen.

This tutorial walks through how to fix the WordPress database connection error in five sequential checks. You verify credentials in wp-config.php and test the connection with phpMyAdmin. The built-in repair tool runs next. Host escalation comes after that. Backup restore is the final option. Roughly 90% of cases finish at Step 1 or Step 2.

What You’ll Need

  • WordPress version: Any version (the error happens before WordPress fully loads).
  • Permissions needed: Hosting panel access for the file manager and MySQL Databases section. FTP access also works.
  • Time to complete: 15 minutes for credential errors. Up to 2 hours if a backup restore is required.
  • Difficulty level: Intermediate. You edit wp-config.php and use phpMyAdmin from the hosting panel.
  • Prerequisites: Database name, user, and password from the hosting panel. Recent backup file as a fallback.

Step 1: Check Database Credentials in wp-config.php

Open your hosting file manager. Navigate to the public_html folder. Find wp-config.php and click Edit. Scroll to the section near the top with these four constants: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.

[SCREENSHOT: wp-config-database-section]

Open the hosting panel in another browser tab. Find the MySQL Databases section. Compare the database name, username, and password line by line against wp-config.php. A single typo in any of these three values triggers the connection error. Copy the correct values from the hosting panel and paste them into wp-config.php. Save the file. Reload the site to confirm the error is gone.

Step 2: Test the Connection via phpMyAdmin

Open the hosting panel and find phpMyAdmin in the Databases section. Click to launch it. Log in using the database username and password from wp-config.php. If the login fails with “access denied”, the credentials are wrong even if they look correct. Reset the database user password from the hosting panel and update wp-config.php with the new value.

[SCREENSHOT: phpmyadmin-login-screen]

If the phpMyAdmin login succeeds, credentials work but DB_HOST might be set wrong. Most shared hosts use “localhost” for DB_HOST. Some hosts (such as DreamHost or older HostGator plans) use a custom hostname like “mysql.yoursite.com”. Find the correct DB_HOST value in your hosting welcome email or support docs.

Step 3: Run the Built-In Database Repair Tool

If credentials and DB_HOST check out but the error persists, the database itself might be corrupted. WordPress ships with a repair tool you must explicitly enable. Add this line to wp-config.php, just above the line that says “/* That’s all, stop editing! */”:

What this does: Activates a hidden repair page at /wp-admin/maint/repair.php that runs MySQL CHECK TABLE and REPAIR TABLE on every WordPress table.

define('WP_ALLOW_REPAIR', true);

[SCREENSHOT: wp-allow-repair-config-line]

Save wp-config.php. Visit yourdomain.com/wp-admin/maint/repair.php in your browser. Click Repair Database. Wait for the process to finish. Remove the WP_ALLOW_REPAIR line from wp-config.php right after to close the public access window.

Step 4: Contact the Host to Confirm the Database Server

The MySQL server itself might be down. This is rare but happens during host migrations, datacenter incidents, or quota overruns. Open a support ticket with your hosting provider. Include the exact error message, the time it started, and the database name from wp-config.php.

[SCREENSHOT: hosting-support-ticket]

Most hosts respond to active outage tickets within 30 minutes. If the host confirms the MySQL server is down, no further action is needed on your side. Wait for the all-clear email and reload the site. If the host says everything looks fine on their end, the issue is local to your install. Step 5 becomes the path forward.

Step 5: Restore from the Last Working Backup

Open your hosting panel. Navigate to UpdraftPlus or your backup tool of choice. Find the most recent backup taken before the error started. Click Restore. Tick all five checkboxes for database, plugins, themes, uploads, and others. Click Restore again to start.

[SCREENSHOT: updraftplus-restore-dialog]

The restore takes 5 to 30 minutes depending on site size. Reload the site after the green success banner appears in the dashboard. If you do not have a recent backup, escalate to the host’s data recovery team. Most hosts keep server-side backups for 7 to 30 days even when the customer has none. Recovery from server backups runs $50 to $200 per restore in 2026.

Troubleshooting

Error: The error appears on some pages but not all.
Fix: A single corrupted table affects only the post types it stores. Run the WP_ALLOW_REPAIR tool from Step 3 to fix the targeted table without restoring the full database.

Error: The error appeared right after a plugin update.
Fix: Rename the plugin folder via FTP at /wp-content/plugins/[plugin-name] to deactivate it. Reload to confirm the plugin caused the error. Roll back to the previous plugin version on WordPress.org.

Error: Credentials look correct but the connection still fails.
Fix: Recreate the database user in the hosting panel with a brand-new password. Update wp-config.php with the new credentials. Old user accounts sometimes lose privileges after host upgrades.

Error: phpMyAdmin shows tables but the WordPress dashboard still errors.
Fix: Check the table prefix in wp-config.php ($table_prefix value) matches the actual prefix in phpMyAdmin (often “wp_” but may differ).

Quick Recap

  • Verified database credentials in wp-config.php against the hosting panel.
  • Tested the connection by logging into phpMyAdmin with the same credentials.
  • Ran the WP_ALLOW_REPAIR tool to fix corrupted database tables.
  • Opened a host support ticket if MySQL server health was in doubt.
  • Restored from the most recent backup as the final fallback.

Set up regular backups so the next outage has a clean restore point. Follow the WordPress backup and restore tutorial. MySQL repair docs live at wordpress.org.

Share.

Lena Kovac writes data-driven analysis and security coverage for WPMytics. She's the person behind the quarterly market reports and monthly trend pieces, using public data from WordPress.org, W3Techs, BuiltWith, and her own testing to map what's happening in the WordPress ecosystem.

Comments are closed.

Exit mobile version