WordPress fout bij databaseconnectie oplossen: stap voor stap

Open je wp-config.php en kijk naar de regels met DB_NAME, DB_USER, DB_PASSWORD en DB_HOST. In negen van de tien gevallen zit het probleem daar, of bij de MySQL-server die er even niet is. De rest van dit artikel loopt de oorzaken na in de volgorde waarin ik ze zelf controleer.

De foutmelding “Error establishing a database connection” betekent dat WordPress de PHP-kant nog goed draait, maar de database niet kan bereiken. Je site is niet kapot. De verbinding is dat.

Ik werk dit door alsof je net bij een laptop zit en je site offline is. Geen theorie vooraf. Eerst de meest waarschijnlijke oorzaak, dan de minder voorkomende.

WordPress fout bij databaseconnectie oplossen: eerst een back-up

Voor je iets aanraakt in wp-config.php of in de database: pak een kopie. Hosting-paneel, een knop “back-up”, desnoods via FTP een snapshot van de map en een export van de database. Een uur extra werk nu is beter dan twee dagen reparatie later.

Dit is geen formaliteit. Foute aanpassingen aan wp-config.php zijn een van de redenen waarom een tijdelijk probleem een serieus probleem wordt. Een back-up voor wijzigingen is bij mij altijd standaard, ook bij kleine taken.

Stap 1: wachtwoord of gebruikersnaam in wp-config.php gewijzigd

De meest voorkomende oorzaak in mijn praktijk. Iemand heeft het databasewachtwoord gereset in het hosting-paneel, maar wp-config.php nog niet bijgewerkt. Vaak gebeurt dat na een hosting-migratie of na een security-actie van de hoster.

Open wp-config.php via FTP, SFTP of de file manager van je hoster. Zoek deze vier regels:

define( 'DB_NAME', 'jouw_database_naam' );
define( 'DB_USER', 'jouw_database_gebruiker' );
define( 'DB_PASSWORD', 'jouw_wachtwoord' );
define( 'DB_HOST', 'localhost' );

Vergelijk ze met wat in het hosting-paneel staat onder MySQL-databases. Wijk er ook maar één teken af, dan kan WordPress geen verbinding maken. Let vooral op spaties aan het begin of einde van het wachtwoord. Die sluipen erin bij kopiëren.

Een wachtwoord met aanhalingstekens of een dollarteken kan ook problemen geven. Gebruik in wp-config.php enkele aanhalingstekens (') rond het wachtwoord. Dubbele aanhalingstekens (") interpreteren PHP-variabelen, en dat is niet wat je wil.

Stap 2: DB_HOST klopt niet

Bij veel Nederlandse hosters is DB_HOST gewoon localhost. Maar niet altijd. Sommige delen MySQL af op een aparte host: mysql.jouwhost.nl, db123.cluster-x.eu, of een IP-adres.

Kijk in het hosting-paneel naar de databasedetails. De server-naam die daar staat moet exact zo in DB_HOST. Soms staat er een poortnummer bij, dan wordt het bijvoorbeeld mysql.jouwhost.nl:3306.

Twijfel je tussen localhost en 127.0.0.1? Dat is geen synoniem. localhost gebruikt een unix socket, 127.0.0.1 gaat over TCP. Beide werken meestal, maar als de ene faalt, probeer de andere.

Stap 3: MySQL-server is down of bezig

Bij goedkope shared hosting komt het voor: de MySQL-server is overbelast, gestopt of in onderhoud. Je wp-config.php klopt, maar de database is gewoon niet bereikbaar.

Test dit door in te loggen op je hosting-paneel. Werkt phpMyAdmin? Reageert de databasebeheerpagina? Zo niet, dan ligt het probleem bij de hoster, niet bij jou. Open een ticket of bel de support.

Een snelle indicator: heeft jouw hoster een statuspagina? Veel hosters hebben er een (Hostinger, TransIP, Hetzner). Kijk daar of er een storing wordt gemeld. Dat scheelt een uur ratelen aan je site.

In de tussentijd kun je niets repareren. Wachten. Frustrerend, maar wel de realiteit als je niet zelf de server beheert.

Stap 4: maximaal aantal connecties bereikt

Soms staat de database wel aan, maar weigert hij nieuwe verbindingen. Dat gebeurt bij plotselinge piekverkeer, een rondzwervende crawler, of een plugin die elke seconde queries afvuurt.

In de foutmelding staat dan vaak iets als “Too many connections” of “Can’t connect to MySQL server”. Een korte stop-en-start van de site lost dit meestal op. Maar als het terugkomt, zit het echte probleem dieper:

• een plugin die ongezond gedrag vertoont (vooral oudere backup- of statistiek-plugins)
• bots die je site bestoken zonder rate-limiting
• een te krap connectie-limiet op shared hosting

Kijk welke plugin recent is bijgewerkt of nieuw geïnstalleerd. Soms kun je via SFTP de map wp-content/plugins/[naam] tijdelijk hernoemen naar [naam]-uit. WordPress schakelt zo’n plugin dan uit. Werkt je site weer? Dan heb je de boosdoener.

Stap 5: corrupte database of tabel

Een minder vaak voorkomende oorzaak: een tabel in de database is corrupt geraakt. Dat zie je soms aan een aanvullende melding: “One or more database tables are unavailable”.

WordPress heeft een ingebouwde reparatiefunctie. Voeg deze regel toe aan wp-config.php, ergens boven de regel met /* That's all, stop editing! */:

define( 'WP_ALLOW_REPAIR', true );

Bezoek daarna https://jouwsite.nl/wp-admin/maint/repair.php. Je krijgt twee knoppen: “Repair Database” en “Repair and Optimize Database”. Begin met de eerste. Dit kan een paar minuten duren.

Belangrijk: haal de regel WP_ALLOW_REPAIR daarna weer weg uit wp-config.php. Anders is die reparatiepagina publiek toegankelijk voor iedereen die de URL kent.

Werkt de ingebouwde repair niet? Dan kan het via phpMyAdmin. Vink de tabellen aan, kies onderin “Repair table”. Voor zwaardere reparaties bestaat de SQL-opdracht CHECK TABLE en REPAIR TABLE.

Stap 6: schijfruimte vol

Onderschat dit niet. Een server waarvan de schijf vol zit, kan geen nieuwe writes meer doen. MySQL stopt dan, of weigert verbindingen. Zelfs een logfile die uit de hand loopt kan dit veroorzaken.

Check via je hosting-paneel de schijfgebruik-overzichten. Vaak liggen de grootste boosdoeners hier:

• de map wp-content/uploads met jaren aan foto’s
• error-logs in wp-content/debug.log of error_log in de root
• back-ups die plugins lokaal opslaan in plaats van extern
• databaselogs en binlogs op de server

Een mailbox die volloopt op dezelfde server is ook een klassieker. Mail op dezelfde hosting als je site, met onbeheerde nieuwsbrieven uit 2019: dan duurt het niet lang.

Stap 7: hack of malware

Komt minder vaak voor als oorzaak van een databaseconnectiefout, maar wel als gevolg. Een gehackte site die geblokkeerd is door de hoster geeft soms een databasefout, omdat de database als veiligheidsmaatregel is afgesloten.

Heb je recent geen wachtwoord gewijzigd, geen plugin bijgewerkt, geen migratie gedaan, en is je site ineens dood? Check je mail. Veel hosters sturen een melding bij verdachte activiteit. Eventueel staat er ook iets in het hosting-paneel onder “Beveiliging” of “Meldingen”.

Bij een bevestigde hack stopt het eenvoudige werk. Een herstelactie loopt dan via een schone back-up, een malware-scan en hardening achteraf. Op de pagina WordPress malware verwijderen staat hoe ik dat aanpak.

Wat je niet moet doen

Een paar dingen waar mensen zichzelf mee in de problemen werken.

Niet zomaar plugins herinstalleren via FTP. Dat verandert de connectie naar de database niet. Het maakt vaak alleen meer rommel.

Niet de database “leeg gooien en opnieuw beginnen”. Dat is geen oplossing, dat is verlies van alle content, gebruikers, instellingen en bestellingen. Eerst de oorzaak, dan pas drastische maatregelen.

Niet wp-config.php aanpassen zonder backup van het bestand zelf. Dit klein bestand is de sleutel tot je hele site. Kopieer hem voor je iets wijzigt.

Niet eindeloos proberen via dezelfde route. Heb je een uur lang dezelfde stappen herhaald zonder resultaat? Dan zit het probleem ergens anders. Of het ligt bij de hoster, of het is iets dat een tweede paar ogen nodig heeft.

Wanneer is het tijd voor hulp

De meeste databaseconnectiefouten zijn binnen een half uur op te lossen als je weet waar je moet kijken. Wat dat halve uur uitloopt, is meestal het zoeken zelf.

Bij mij is dit standaardwerk. Migratie, serverwerk en database vallen onder mijn 95 euro per uur tarief, of 105 euro per uur als het buiten kantooruren moet. Tijdregistratie afgerond per 15 minuten, minimum per factuur 50 euro. Allemaal exclusief btw.

In de praktijk lossen veel databasefouten zich op binnen één tot twee uur werk, inclusief het uitzoeken. Een gehackte site of een corrupte productie-database kost meer, omdat daar herstel achteraan komt.

Wat ik graag vooraf weet: de exacte foutmelding, de naam van je hoster, of er recent iets is gewijzigd (migratie, wachtwoord, plugin-update), en hoelang het probleem al speelt. Met die info kan ik direct een gerichte schatting maken in plaats van een blinde duik.

Verbeteren boven herbouwen. Een werkende site weer aan de praat krijgen is bijna altijd goedkoper dan een nieuwe bouwen. Ook al voelt het in het moment niet zo. Meer artikelen over WordPress staan in de categorie website onderhoud.