Wat betekent Error establishing a database connection in WordPress?

WordPress kan geen bruikbare verbinding met de ingestelde MySQL- of MariaDB-database maken. Dat kan komen door onjuiste verbindingsgegevens, een onbereikbare databaseserver, een ingetrokken databasegebruiker of beschadigde tabellen.

Moet ik DB_HOST altijd op localhost zetten?

Nee. DB_HOST kan localhost zijn, maar een host kan ook een andere servernaam, poort of socket voorschrijven. Neem de waarde exact over uit het hostingpaneel of laat de hostingprovider bevestigen welke waarde bij jouw database hoort.

Kan ik mijn databasewachtwoord veilig testen?

Test het bij voorkeur via het beveiligde databasebeheer van je hostingprovider of laat de provider de koppeling controleren. Zet het wachtwoord nooit in een openbaar script, schermafbeelding, chatbericht of logbestand.

Waarom verschijnt de databasefout maar af en toe?

Een wisselende fout past vaker bij overbelasting, een verbindingslimiet, een herstartende databaseserver of een netwerkprobleem dan bij permanent verkeerde inloggegevens. Noteer tijdstippen en laat de host de database- en resourcelogs rond die momenten controleren.

Wanneer gebruik ik WP_ALLOW_REPAIR?

Alleen wanneer er concrete aanwijzingen zijn voor beschadigde tabellen en nadat je een herstelbare databaseback-up hebt gemaakt. Verwijder de constante direct na de reparatie, want de reparatiepagina vereist tijdens het gebruik geen WordPress-login.

Kan ik een back-up maken als WordPress niet opent?

Vaak wel via het hostingpaneel, phpMyAdmin, een database-export of een recente hostingsnapshot. Een bestandenback-up alleen bevat normaal niet je berichten en instellingen, dus controleer dat je ook een databasekopie of herstelpunt hebt.

Wanneer moet ik mijn hostingprovider inschakelen?

Schakel de provider in als de databaseserver niet bereikbaar is, je geen veilige back-up of databasebeheer hebt, de fout wisselend terugkomt of logs wijzen op limieten, rechten of serverstoringen. Deel tijdstip en fouttype, maar geen wachtwoorden.

Error establishing a database connection in WordPress oplossen (2026)

De melding Error establishing a database connection betekent dat WordPress geen bruikbare verbinding met de ingestelde database kan maken. Controleer eerst of de databaseserver beschikbaar is en vergelijk daarna de vier database-instellingen in wp-config.php met het hostingpaneel, zonder wachtwoorden te tonen of meerdere onderdelen tegelijk te wijzigen.

Wat deze melding wel en niet vertelt

WordPress bewaart berichten, pagina's, gebruikers en veel instellingen in MySQL of MariaDB. PHP kan nog draaien terwijl die database niet bereikbaar is. De fout zegt daarom niet automatisch dat de database beschadigd is en ook niet dat WordPress opnieuw moet worden geïnstalleerd.

De meest bruikbare eerste scheiding is:

De hele site en /wp-admin/ tonen dezelfde fout. Denk eerst aan de databaseserver, verbindingsgegevens, rechten of een gewijzigde hostnaam.
De fout verschijnt alleen af en toe. Denk aan capaciteitsproblemen, een verbindingslimiet, een herstart of een netwerkstoring. Permanente verkeerde gegevens geven meestal een permanente fout.
Het beheergedeelte meldt dat tabellen niet beschikbaar zijn. Onderzoek pas dan of er aanwijzingen voor tabelschade zijn.
De fout begon direct na een migratie, wachtwoordwijziging of herstelactie. Controleer precies die ene gewijzigde laag voordat je elders ingrijpt.

Krijg je in plaats daarvan een algemene servermelding, volg dan de aparte aanpak voor een 500 Internal Server Error. Zie je een PHP-fout of herstelmail, begin bij de kritieke WordPress-fout.

Eerst veiligstellen: back-up, bewijs en rollback

Maak vóór een wijziging één herstelset van de database en de bestanden. De officiële WordPress-uitleg over back-ups benadrukt dat een volledige site uit beide delen bestaat. Een kopie van alleen wp-content of alleen de database is dus geen volledige rollback.

Als de database nu niet bereikbaar is, kun je mogelijk geen nieuwe export maken. Controleer dan in het hostingpaneel of er een recente, herstelbare snapshot staat en download in elk geval wp-config.php, .htaccess en wp-content. Noteer de datum en het tijdstip van het herstelpunt. Start geen reparatie of import voordat je weet welk herstelpunt je kunt terugzetten.

Leg daarnaast vast:

het exacte tijdstip waarop je de fout ziet;
of de voorkant en /wp-admin/ hetzelfde reageren;
welke update, migratie of hostingwijziging eraan voorafging;
welke stap je test en hoe je die terugdraait.

Kopieer nooit DB_PASSWORD, andere geheimen, persoonsgegevens of volledige configuratiebestanden naar een ticket of log. Maak schermafbeeldingen pas nadat je gevoelige waarden onleesbaar hebt gemaakt.

Stap voor stap de databaseverbinding herstellen

1. Controleer of het een algemene hostingstoring is

Open het hostingpaneel en controleer de status van webserver en database. Kijk of andere sites op hetzelfde account dezelfde databasefout geven. Een databaseserver die gestopt, onbereikbaar of in onderhoud is, kun je niet repareren door WordPress-bestanden te wijzigen.

Vraag de host bij twijfel gericht om deze punten te controleren:

is de MySQL- of MariaDB-service bereikbaar vanaf de webserver;
is de databasegebruiker actief en gekoppeld aan de juiste database;
zijn verbindings- of resourcelimieten bereikt;
staat rond jouw genoteerde tijdstip een relevante fout in de server- of databaselog.

Wijzig intussen niets. Als de host een storing bevestigt, wacht je op herstel en test je daarna opnieuw.

2. Controleer of de database bestaat en bereikbaar is

Open het databasebeheer vanuit het beveiligde hostingpaneel. Controleer of de databasenaam bestaat en of je tabellen herkent, vaak met een prefix zoals wp_. Voer nog geen herstel, optimalisatie, import of verwijderactie uit.

Kun je het databasebeheer niet openen, dan is dat extra bewijs voor een server-, account- of rechtenprobleem. Kun je de database wel openen, dan bewijst dat alleen dat jouw paneelsessie werkt. WordPress gebruikt mogelijk een andere databasegebruiker. Laat de host die koppeling verifiëren als je die niet veilig zelf kunt testen.

Installeer geen los PHP-testbestand met databasegegevens in een publiek bereik. Zo'n script kan inloggegevens lekken en moet daarna weer worden opgespoord. Het hostingpaneel of ondersteuning van de provider is een veiligere grens.

3. Maak een veilige kopie van wp-config.php

Download wp-config.php uit de WordPress-hoofdmap en bewaar een ongewijzigde kopie met datum. Bewerk een lokale kopie in een gewone teksteditor, niet in een tekstverwerker. Controleer vóór upload welke bestandsrechten en eigenaar de bestaande versie heeft.

De officiële documentatie voor wp-config.php benoemt vier waarden voor de verbinding:

define( 'DB_NAME', 'jouw_databasenaam' );
define( 'DB_USER', 'jouw_databasegebruiker' );
define( 'DB_PASSWORD', 'jouw_databasewachtwoord' );
define( 'DB_HOST', 'jouw_databasehost' );

Deze waarden zijn alleen plaatsaanduidingen. Publiceer nooit jouw echte waarden en plak ze niet in een diagnosebericht.

4. Vergelijk iedere databasewaarde zonder te gokken

Vergelijk DB_NAME, DB_USER, DB_PASSWORD en DB_HOST één voor één met de gegevens in het hostingpaneel. Let op hoofdletters, ongewenste spaties en ontbrekende aanhalingstekens. DB_HOST is niet overal localhost: de host kan een servernaam, alternatieve poort of socket voorschrijven.

Verander alleen een waarde wanneer je een aantoonbaar verschil hebt gevonden. Upload de aangepaste kopie, laad één testpagina en leg het resultaat vast. Werkt het niet, zet dan de vorige wp-config.php terug voordat je een andere hypothese onderzoekt.

Reset het databasewachtwoord niet als eerste gok. Een reset maakt alle andere toepassingen met die gebruiker ongeldig en creëert een tweede wijziging. Is een reset noodzakelijk, plan dan vooraf waar de nieuwe waarde moet worden bijgewerkt en hoe je teruggaat als de wijziging mislukt.

5. Controleer gebruiker en rechten

De databasegebruiker moet aan de bedoelde database gekoppeld zijn met passende rechten. Bij sommige hosts raakt die koppeling kwijt na een migratie, accountwijziging of databaseherstel. Controleer in het paneel de koppeling zonder bestaande gebruikers of databases te verwijderen.

Maak niet direct een nieuwe database en importeer ook niet blind een oude kopie. Daarmee kun je een bereikbaarheidsprobleem veranderen in dataverlies of een site met verouderde inhoud. Laat de provider rechten herstellen wanneer het paneel niet duidelijk toont welke wijziging veilig is.

6. Lees logs rond één exact tijdstip

Controleer eerst de PHP-, webserver- en databaselog die je host aanbiedt. Zoek rond het tijdstip van jouw test naar termen als verbinding geweigerd, onbekende database, toegang geweigerd, time-out of te veel verbindingen. Noteer het fouttype en eventueel een referentienummer, maar neem geen wachtwoord, queryinhoud of persoonsgegevens over.

WordPress-logging kan helpen als WordPress ver genoeg opstart, maar een vroege databasefout kan optreden voordat een bruikbaar logbericht wordt geschreven. Als je tijdelijk logt, volg dan de officiële WordPress-debuginstellingen: houd WP_DEBUG_DISPLAY op false op productie en bescherm het logbestand tegen publieke toegang. Verwijder of archiveer het log na de diagnose.

Een leeg log bewijst dus niet dat de database gezond is. Het betekent alleen dat deze loglaag geen bruikbaar bericht heeft vastgelegd.

7. Draai een recente wijziging gecontroleerd terug

Begon de fout na een migratie, herstelactie of wijziging van de databasehost, zet dan uitsluitend die wijziging terug. Gebruik de gedocumenteerde oude wp-config.php, het vorige databaseherstelpunt of de oude hostwaarde. Test daarna zowel de startpagina als /wp-admin/.

Een plugin uitschakelen is bij deze specifieke melding niet de eerste stap. WordPress moet de databaseverbinding al vroeg opbouwen, nog voordat normale plugins volledig laden. Een geavanceerde drop-in zoals wp-content/db.php kan wel invloed hebben. Verplaats zo'n bestand alleen als je weet welke toepassing het heeft geleverd en een exacte rollback hebt.

8. Repareer tabellen alleen bij concreet bewijs

Gebruik databaseherstel niet voor een verkeerde hostnaam of een uitgevallen server. Zie je een expliciete melding over beschadigde tabellen en heb je een herstelbare databasekopie, dan ondersteunt WordPress tijdelijk:

define( 'WP_ALLOW_REPAIR', true );

De reparatiepagina staat daarna op /wp-admin/maint/repair.php. WordPress waarschuwt in de wp-config.php-documentatie dat deze pagina geen login vereist zolang de constante actief is. Voeg de regel daarom alleen voor de reparatie toe, kies geen optimalisatie zonder reden en verwijder de regel direct erna.

Stop als de reparatie fouten geeft of tabellen ontbreekt. Importeer dan niet over de actieve database heen, maar laat een specialist of je host eerst de back-up en schade beoordelen.

9. Test herstel en sluit de diagnose af

Controleer na iedere geslaagde stap:

de startpagina en een inhoudspagina;
/wp-admin/ en een veilige leesactie;
of de fout na enkele minuten en in een privésessie wegblijft;
of de hostinglogs geen nieuwe verbindingsfout tonen.

Zet tijdelijke logging uit, verwijder reparatietoegang en bewaar de werkende configuratie veilig. Verwijder gevoelige downloads van een gedeelde computer. Noteer de oorzaak en de ene wijziging die hielp, zodat je een terugkerend capaciteitsprobleem niet opnieuw als wachtwoordfout behandelt.

Veelgemaakte fouten

Alle waarden in wp-config.php tegelijk aanpassen. Daardoor weet je niet welke wijziging werkte en heb je geen heldere rollback.
Aannemen dat DB_HOST altijd localhost is. De juiste host kan ook een servernaam, poort of socket bevatten.
Databasegegevens delen in een ticket of schermafbeelding. Een wachtwoord hoort nooit in publiek bewijs, chat of logging.
Meteen een nieuw databasewachtwoord instellen. Dat kan andere koppelingen breken en maakt de diagnose ingewikkelder.
Alleen bestanden back-uppen. WordPress-inhoud staat grotendeels in de database en vereist een aparte export of snapshot.
Blind tabellen repareren of optimaliseren. Reparatie helpt niet tegen een onbereikbare databaseserver of verkeerde inloggegevens.
WP_ALLOW_REPAIR laten staan. De reparatiepagina is dan zonder WordPress-login bereikbaar.
Een willekeurig verbindingstestscript uploaden. Zo kunnen databasegeheimen via de webserver uitlekken.
Een wisselende fout als configuratiefout behandelen. Intermitterende fouten vragen juist om tijdstippen, resourcegegevens en serverlogs.

Wanneer je beter stopt

Stop met zelf wijzigen als je geen recente back-up kunt verifiëren, de database niet in het hostingpaneel ziet, tabellen ontbreken of de provider een serverprobleem meldt. Stop ook wanneer een productieomgeving bestellingen, reserveringen of andere actuele gegevens verwerkt: een oude database terugzetten kan nieuwe transacties overschrijven.

Geef een beheerder of hostingprovider de domeinnaam, het exacte tijdstip, de getroffen routes, recente wijzigingen en het fouttype uit een veilig opgeschoond log. Geef nooit databasewachtwoorden door. Voor een bredere beslisroute bij andere storingen ga je terug naar de WordPress-hub, of lees hoe je een wit scherm in WordPress van een databasefout onderscheidt.

Wil je dat iemand de databaseverbinding en herstelroute gecontroleerd onderzoekt, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.