Je opent je site en ziet alleen nog één regel tekst, “Er is een fout bij het maken van een databaseverbinding” (in het Engels “Error establishing a database connection”). Ook wp-admin doet het niet meer. De databaseverbindingsfout betekent dat WordPress de MySQL-database niet kan bereiken. Controleer de databasegegevens in wp-config.php, of de databaseserver draait en of de database niet beschadigd is; repareer met WP_ALLOW_REPAIR of zet een back-up terug.
Schrik niet. Je pagina’s en orders staan vrijwel altijd nog in de database, alleen de weg ernaartoe is geblokkeerd.
Wat betekent ‘error establishing a database connection’?
Error establishing a database connection betekent dat WordPress geen verbinding krijgt met de MySQL- of MariaDB-database waarin al je inhoud en instellingen staan. Ik vergelijk het vaak met een archiefkast. Alles van je site ligt erin, maar WordPress heeft de verkeerde sleutel, of de kast staat in een ruimte die op slot zit. Meer achtergrond in hoe WordPress, PHP en de database samenwerken.
Zie je in wp-admin “Een of meer databasetabellen zijn niet beschikbaar”, dan werkt de verbinding wel, maar zijn tabellen beschadigd. En “Cannot select database” betekent dat de inloggegevens kloppen, terwijl de database zelf ontbreekt, een andere naam heeft of de gebruiker er geen rechten op heeft.
| Wat je ziet of net hebt gedaan | Waarschijnlijke oorzaak | Begin bij |
|---|---|---|
| Net verhuisd of databasewachtwoord gewijzigd | Gegevens in wp-config.php kloppen niet | Stap 1 |
| Melding “Cannot select database” | Database verwijderd, hernoemd of zonder rechten | Stap 1 |
| Ook phpMyAdmin of andere sites op je account werken niet | Databaseserver plat of overbelast | Stap 2 |
| Fout komt en gaat bij drukte | Connectielimiet of te weinig serverresources | Stap 2 |
Melding in wp-admin over niet-beschikbare tabellen | Beschadigde tabellen | Stap 3 |
wp-config.php is aangepast terwijl niemand iets wijzigde, of er staan onbekende bestanden | Mogelijke hack | Scan op malware en lees WordPress website gehackt, wat nu? of laat het herstel doen via WordPress gehackt |
In de meeste gevallen die ik zie, gaat het om de eerste rij. Download wel eerst een kopie van wp-config.php en controleer of er een recente back-up is, want één typfout in dat bestand geeft je meteen een nieuwe fout. Vermoed je een hack, dan helpt het dat Imunify op de shared pakketten van Surver elke bestandswijziging scant.
Stap 1: controleer de databasegegevens in wp-config.php
De databasegegevens in wp-config.php moeten exact overeenkomen met de database en databasegebruiker in je hostingpaneel, en juist daar gaat het meestal mis.
- Open
wp-config.phpin de hoofdmap van je site via File Manager in cPanel of via (S)FTP. - Zoek de vier regels
define( 'DB_NAME', 'databasenaam' );,define( 'DB_USER', 'databasegebruiker' );,define( 'DB_PASSWORD', 'wachtwoord' );endefine( 'DB_HOST', 'localhost' );. - Vergelijk ze in cPanel onder MySQL-databases met de naam van de database en de databasegebruiker.
- Twijfel je over het wachtwoord, stel dan in je hostingpaneel een nieuw wachtwoord in voor de databasegebruiker en zet precies hetzelfde in
DB_PASSWORD. - Controleer op dezelfde plek of de gebruiker met alle rechten aan de database is gekoppeld.
- Sla het bestand op en ververs je site.
Let bij het bewerken op de kleine dingen. Gebruik rechte enkele aanhalingstekens en geen krulquotes uit Word of een mail en zet geen spaties binnen de aanhalingstekens. DB_HOST is meestal localhost, maar sommige hostingpartijen gebruiken een andere servernaam of poort, dus vraag het na als je twijfelt. Krijg je de fout vlak na een verhuizing, dan staan er vaak nog gegevens van de oude host in het bestand. Het complete stappenplan staat in WordPress-website verhuizen, en wil je het niet zelf doen, dan regelt onze verhuisservice ook de databasegegevens.
Stap 2: controleer of de databaseserver draait
Kun je in cPanel niet inloggen in phpMyAdmin, dan ligt het probleem niet bij WordPress maar bij de databaseserver. Kijk ook of andere sites op je account werken en of je host een storing meldt. Bij Surver zie je dat op status.surver.nl. Meestal gaat het om overbelasting door te veel gelijktijdige verbindingen (de melding “too many connections”), een volle schijf of een herstart van de server. Loopt een drukke site hier vaker tegenaan, dan is managed cloud hosting het overwegen waard.
Hier wil ik eerlijk zijn. Ligt de databaseserver plat, dan kun je zelf weinig doen. Dat is het werk van je hostingpartij, en die hoort het ook te melden. Neem contact op en noem het tijdstip en wat je al hebt gecontroleerd. Een PHP-testscript met je databasewachtwoord, zoals sommige handleidingen aanraden, zet ik liever niet op de server, want zo’n bestand blijft vaak vergeten staan. Wil je breder kijken waarom je site onbereikbaar is, lees dan WordPress-website offline.
Stap 3: repareer beschadigde databasetabellen
Beschadigde tabellen herstel je met een reparatie via phpMyAdmin, WP-CLI of de ingebouwde reparatiepagina van WordPress, in die volgorde van voorkeur. Tabellen raken beschadigd, of corrupt, na een servercrash, een volle schijf of een update die halverwege afbreekt.
De eenvoudigste route is phpMyAdmin. Kies je database, selecteer alle tabellen en kies onderaan Tabel repareren. Werk je liever met de commandoregel, dan kan dat via SSH met WP-CLI, die op alle shared pakketten van Surver beschikbaar is. Met wp db check zie je welke tabellen fout zijn, en wp db repair repareert ze.
Lukt geen van beide, dan heeft WordPress een eigen reparatiepagina. Zet de regel define( 'WP_ALLOW_REPAIR', true ); in wp-config.php, boven de regel /* That's all, stop editing! */. Ga daarna naar jouwdomein.nl/wp-admin/maint/repair.php en kies Database repareren.
Verwijder die regel direct na de reparatie. Zolang WP_ALLOW_REPAIR aan staat, kan iedereen die pagina zonder inloggen openen. Daarom gebruik ik deze route alleen als phpMyAdmin en WP-CLI niet beschikbaar zijn.
Stap 4: zet een back-up terug als niets helpt
Werkt niets van het bovenstaande, vervang dan eerst de kernbestanden en zet pas daarna een back-up terug. Upload verse mappen wp-admin en wp-includes van wordpress.org en laat wp-content en wp-config.php staan. Helpt dat niet, zet dan de database terug van vóór het probleem. Op de shared pakketten van Surver doe je dat zelf en kosteloos met JetBackup 5 in cPanel, waarin je los kiest voor alleen de database of alleen de bestanden. Maak vooraf wel een back-up van de huidige staat, want die wordt bij terugzetten niet automatisch bewaard. Zie back-up terugzetten.
Bij een WooCommerce-webshop verdwijnt alles wat na het back-upmoment is gebeurd, dus ook orders, klantaccounts en voorraadmutaties. Noteer vooraf de orders uit je betaalprovider en de WooCommerce-mails. Repareren gaat daarom altijd vóór terugzetten, want een back-up terugzetten op een draaiende webshop kost je de orders van vandaag. Meer daarover in WooCommerce back-up.
Wat we bij Surver doen, is de servers bewaken, ook de databaseserver. Zit de fout in je site zelf, dan heb je op onze managed WordPress hosting alles bij de hand, van phpMyAdmin en File Manager in cPanel tot SSH en WP-CLI. Om herhaling te voorkomen, wijzig je het databasewachtwoord alleen samen met wp-config.php en test je na een verhuizing de verbinding voordat je de DNS omzet. Met uptime monitoring weet je het eerder dan je klanten, en binnen WordPress beheer controleert Surver elke minuut of je site bereikbaar is. Krijg je een andere melding, kijk dan in het overzicht van WordPress-foutmeldingen.
Veelgestelde vragen
Is mijn content weg bij deze fout?
Meestal niet. De fout gaat over de verbinding naar de database, niet over de gegevens zelf, dus je pagina’s, berichten en orders staan er nog. Alleen bij ernstige beschadiging heb je een back-up nodig.
Waarom krijg ik deze fout na een verhuizing?
Meestal kloppen databasenaam, gebruiker, wachtwoord of host in wp-config.php niet met de nieuwe hosting. Soms is de database nog niet geïmporteerd of hangt de gebruiker er nog niet aan.
Kan Surver dit voor mij oplossen?
Ligt het aan de databaseserver, dan is dat het werk van Surver, en storingen zie je op status.surver.nl. Zit de oorzaak in je site, dan zet je zelf de database terug met JetBackup 5 of vraag je support om mee te kijken. Een hersteltijd beloven we vooraf niet.
