Fout bij de databaseverbinding in WordPress: zo los je het op

Je laadt je site en elke pagina — voorkant en wp-admin allebei — is vervangen door één grijze zin: Fout bij het tot stand brengen van een databaseverbinding. Er wordt niets weergegeven, want er kan niets. WordPress is niet eens toegekomen aan het opbouwen van een pagina.

Hier is het denkmodel dat dit snel oplosbaar maakt. WordPress bewaart al je inhoud — berichten, pagina’s, instellingen, gebruikers — in een MySQL-database, niet in bestanden. Bij elke aanvraag leest het vier inloggegevens uit wp-config.php, maakt verbinding met die database en haalt op wat het nodig heeft. Deze fout betekent dat die verbinding is geprobeerd en geweigerd. De oplossing is uitzoeken waarom hij werd geweigerd, en daar zijn maar drie mogelijkheden voor.

De drie oorzaken, op volgorde van waarschijnlijkheid

1. Een verkeerd inloggegeven in wp-config.php — meestal het gevolg van een hostverhuizing.
2. De databaseserver is uitgevallen of overbelast — meestal het gevolg van niets veranderd aan jouw kant.
3. De database is beschadigd — minder vaak, en kondigt zich anders aan.

Werk ze in die volgorde af.

Stap 1: controleer de vier inloggegevens

Open wp-config.php in de root van je site via SFTP of de bestandsbeheerder van je host. Vier regels bepalen de verbinding:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Elk van deze moet exact overeenkomen met wat je host heeft toegewezen. Open de databasesectie van je hostingpaneel (in cPanel heet die “MySQL-databases”) en vergelijk teken voor teken:

• DB_NAME — hosts zetten vaak je account als voorvoegsel voor de naam, zoals cpaneluser_wpdb. Dat voorvoegsel hoort bij de naam.
• DB_USER — hetzelfde voorvoegsel geldt hier, en de gebruiker moet aan die database zijn toegewezen, niet alleen bestaan.
• DB_PASSWORD — verreweg de meest voorkomende boosdoener. Weet je het niet zeker, reset het dan in het paneel en plak de nieuwe waarde erin. Let op een spatie aan het eind of een slim aanhalingsteken.
• DB_HOST — ga niet uit van localhost. Veel hosts gebruiken een aparte databaseserver met een adres als mysql.yourhost.com, soms met een :port. Het paneel toont de juiste waarde.

Omdat juist in dit bestand deze vier waarden staan, is de veiligste manier om een schone, correct aangehaalde wp-config.php opnieuw op te bouwen de wp-config.php-generator — vul de vier databasevelden in en plak het resultaat over het oude blok.

Deze stap alleen al lost de fout op na vrijwel elke migratie, want inloggegevens die op de oude host klopten, zijn op de nieuwe verkeerd.

Stap 2: bevestig dat de databaseserver echt draait

Als de inloggegevens kloppen en de fout blijft — vooral als hij vanzelf verscheen zonder dat jij iets veranderde — is de databaseserver zelf de verdachte.

Bij shared hosting komt dit vaak voor en is het meestal tijdelijk: de MySQL-dienst raakt overbelast tijdens piekverkeer of bereikt zijn verbindingslimiet per account en begint nieuwe verbindingen te weigeren. Meestal herstelt hij binnen een paar minuten. Herlaad na een korte pauze voordat je iets ingrijpends doet.

Om te testen of de inloggegevens überhaupt geldig zijn los van WordPress, zet je een piepklein script naast wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Gebruik je echte DB_HOST, DB_USER en DB_PASSWORD. Print het Connected, dan werken je inloggegevens en zit het probleem elders (een beschadigde database, stap 3). Print het een verbindingsfout, dan vertelt de melding welke: “Access denied” betekent een verkeerde gebruiker of wachtwoord; “Can’t connect to MySQL server” betekent een verkeerde host of een echt uitgevallen dienst — tijd om je host te bellen. Verwijder het script zodra je klaar bent.

Stap 3: herstel een beschadigde database

Eén teken onderscheidt beschadiging van een verbindingsprobleem: de voorkant laadt maar wp-admin toont de fout, of andersom. Was de verbinding echt geweigerd, dan zouden beide dood zijn. Zo’n splitsing wijst op beschadigde tabellen.

WordPress heeft een ingebouwd herstelgereedschap. Voeg één regel toe aan wp-config.php, boven de opmerking “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Ga daarna rechtstreeks naar deze URL in je browser:

https://yoursite.com/wp-admin/maint/repair.php

Hij laadt zonder login — dat is de bedoeling, want je bent misschien buitengesloten — en biedt “Database repareren” en “Database repareren en optimaliseren” aan. Voer het uit.

Verwijder die regel daarna meteen uit wp-config.php. Zolang hij aanwezig is, kan iedereen op internet die URL aanroepen en een herstel op je database uitvoeren. Dit is geen optionele opruiming; het is het dichten van een gat dat je zojuist hebt geopend.

Stap 4: als het herstel niet eens verbinding maakt

Toont de herstelpagina zelf de verbindingsfout, dan is er niets te herstellen — de database is helemaal niet bereikbaar, dus je bent terug bij stap 1 of stap 2. Op dat punt is de betrouwbare zet om de database te herstellen vanuit de meest recente back-up van je host. De meeste panelen bewaren automatische dagelijkse database-snapshots; een herstel van gisteravond is vrijwel altijd sneller en veiliger dan jagen op een beschadiging waarmee je geen verbinding kunt maken.

Advies dat je gerust kunt negeren

“Installeer WordPress gewoon opnieuw.” Deze fout gaat over de databaseverbinding, niet over corebestanden. Opnieuw installeren vervangt juist de bestanden die prima werken en raakt niets aan wat kapot is.

“Verhoog je PHP-geheugenlimiet.” Geheugentekort is een andere fout met een andere melding. De limiet verhogen doet niets voor een geweigerde databaseverbinding en verhult alleen dat je de inloggegevens nooit hebt gecontroleerd.

“Leeg je cache.” De fout treedt op in PHP voordat een cache ook maar een pagina kan uitleveren. De cache legen verandert niets zolang de verbinding wordt geweigerd; het is pas de moeite waard nadat de site terug is.

“Bewerk de database rechtstreeks om het op te lossen.” Naar phpMyAdmin grijpen om tabellen met de hand te bewerken voordat je hebt bevestigd dat de verbinding überhaupt werkt, is hoe een tijdelijke storing permanent gegevensverlies wordt. Bevestig eerst de verbinding; raak de gegevens als laatste aan, en alleen vanuit een back-up.

Kom je er niet uit?

Als de inloggegevens kloppen volgens het testscript, de server draait, en het herstel verbinding maakt en geen fouten meldt, maar de site nog steeds de melding toont, dan is de resterende verdachte een plugin die op een eigen verbinding met de database praat — een caching- of databaseplugin die een verouderde host heeft opgeslagen. Hernoem wp-content/plugins via SFTP naar plugins-off om dat uit te sluiten. Verdwijnt de fout, voer de plugins dan één voor één opnieuw in tot hij terugkomt.