Fout bij het maken van de databaseconnectie in WordPress: wat het betekent

Wat de melding zegt

Voor elke pagina die hij toont, opent WordPress een verbinding met zijn MySQL- of MariaDB-database, met vier gegevens die in wp-config.php staan, in de root van de site:

define( 'DB_NAME', 'naam_van_de_database' );
define( 'DB_USER', 'gebruikersnaam' );
define( 'DB_PASSWORD', 'wachtwoord' );
define( 'DB_HOST', 'localhost' );

“Fout bij het maken van de databaseconnectie” betekent dat deze verbinding is mislukt. Vier oorzaken leiden ertoe: gegevens die niet meer kloppen, een databaseserver die uitgevallen of onbereikbaar is, een overbelaste server, of een beschadigde database. De secties hieronder lopen ze langs, van de eenvoudigst te controleren tot de zeldzaamste.

1. Reageert de databaseserver?

• De statuspagina van de hostingprovider: een storing of onderhoud aan de MySQL-server wordt daar aangekondigd.
• De andere sites op hetzelfde account: tonen ze op hetzelfde moment dezelfde fout, dan ligt de oorzaak bij de server, en de oplossing bij de hostingprovider.
• phpMyAdmin, vanuit het paneel van de hostingprovider: opent het de database en toont het de tabellen, dan werkt de server en bestaat de database.

Ligt het aan de server, open dan een ticket bij de hostingprovider met het tijdstip waarop de storing begon en de exacte melding. Aan de site hoeft u intussen niets te wijzigen.

2. Kloppen de gegevens in wp-config.php?

Dit is de meest voorkomende oorzaak na een verhuizing van de site, een gewijzigd databasewachtwoord in het paneel van de hostingprovider, of het terugzetten van een back-up. Vergelijk de vier waarden in wp-config.php met het onderdeel databases in het paneel van uw hostingprovider:

• DB_NAME en DB_USER: veel hostingproviders zetten de accountnaam ervoor (account_wordpress). Het voorvoegsel hoort bij de naam.
• DB_PASSWORD: stel bij twijfel in het paneel een nieuw wachtwoord in voor de gebruiker, en zet het in het bestand.
• DB_HOST: localhost bij veel hostingproviders, maar niet bij allemaal. Sommige geven een servernaam of een adres, soms gevolgd door een poort (:3306). De exacte waarde staat in het paneel.
• De gebruiker moet rechten op de database hebben: controleer in het paneel of de gebruiker aan de database is gekoppeld, met alle rechten.

Een wachtwoord met een apostrof (') breekt de PHP-tekenreeks eromheen in wp-config.php af. Zet er een backslash voor (\'), of kies een wachtwoord zonder apostrof.

De gegevens buiten WordPress testen

WordPress toont een algemene melding. MySQL zegt precies wat er misgaat. Twee manieren om het te vragen, met de waarden uit wp-config.php:

Via de opdrachtregel, als u SSH-toegang hebt

mysql -h localhost -u gebruikersnaam -p naam_van_de_database

Met WP-CLI leest wp db check rechtstreeks wp-config.php en controleert het de tabellen met die gegevens.

Met een tijdelijk PHP-bestand

Zet dit bestand onder een moeilijk te raden naam in de root van de site, open het in de browser en verwijder het meteen daarna: het bevat het wachtwoord van de database.

<?php
mysqli_report(MYSQLI_REPORT_OFF);
$verbinding = @mysqli_connect('localhost', 'gebruikersnaam', 'wachtwoord', 'naam_van_de_database');
echo $verbinding ? 'Verbinding gelukt' : 'Mislukt: ' . mysqli_connect_error();

De eerste regel telt: sinds PHP 8.1 werpt een mislukte verbinding standaard een exception op, en de pagina zou wit blijven in plaats van de melding van MySQL te tonen.

3. Een beschadigde database: de reparatietool

Kloppen de gegevens maar zijn er tabellen beschadigd, dan toont de publieke site dezelfde verbindingsfout, en het dashboard een preciezere melding: “Eén of meer databasetabellen zijn niet beschikbaar. De database moet waarschijnlijk worden gerepareerd.” WordPress levert daarvoor een tool. Voeg deze regel toe aan wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Open daarna https://www.uw-site.com/wp-admin/maint/repair.php en start “Database repareren”. Verwijder de regel zodra de reparatie klaar is: zolang hij er staat, is deze pagina voor iedereen bereikbaar, zonder in te loggen.

Maak vóór elke reparatie een export van de database (wp db export, of de export van phpMyAdmin). Mislukt de reparatie, dan kan de hostingprovider de database uit zijn back-ups terugzetten.

4. Een fout die komt en gaat: de belasting

Een fout die op bepaalde uren verschijnt en vanzelf weer verdwijnt, wijst eerder op een overbelaste server dan op een verkeerde instelling. De meest voorkomende oorzaken:

• Een piek in het verkeer, vaak bots: herhaalde inlogpogingen op wp-login.php of xmlrpc.php, zichtbaar in de toegangslogs van de hostingprovider.
• De limieten van gedeelde hosting: het aantal gelijktijdige verbindingen of processen is per account begrensd. Het paneel van de hostingprovider toont ze meestal in het onderdeel over resourceverbruik.
• Een zware plugin: statistieken, logboeken of geplande taken die bij elk bezoek naar de database schrijven.

De oplossingen: misbruikende inlogpogingen blokkeren, een paginacache installeren, xmlrpc.php uitschakelen als geen enkele toepassing het gebruikt, en de hostingprovider om de logbestanden van de periode met de fout vragen.