Fejl ved etablering af databaseforbindelse i WordPress: hvad beskeden betyder

Det, beskeden siger

For hver side, WordPress viser, åbner det en forbindelse til sin MySQL- eller MariaDB-database med fire værdier, der står i wp-config.php i hjemmesidens rodmappe:

define( 'DB_NAME', 'databasenavn' );
define( 'DB_USER', 'brugernavn' );
define( 'DB_PASSWORD', 'adgangskode' );
define( 'DB_HOST', 'localhost' );

«Fejl ved etablering af databaseforbindelse» betyder, at den forbindelse mislykkedes. Fire årsager fører til det: oplysninger, der ikke længere passer, en databaseserver, der er nede eller ikke kan nås, en overbelastet server eller en beskadiget database. Afsnittene nedenfor gennemgår dem fra den nemmeste at tjekke til den sjældneste.

1. Svarer databaseserveren?

• Din udbyders statusside: et nedbrud eller en vedligeholdelse af MySQL-serveren bliver meldt ud dér.
• Andre hjemmesider på samme konto: viser de den samme fejl på samme tidspunkt, ligger årsagen på serversiden, og løsningen ligger hos din udbyder.
• phpMyAdmin, fra dit kontrolpanel: åbner det databasen og viser dens tabeller, kører serveren, og databasen findes.

Er serveren årsagen, så opret en supportsag hos din udbyder med tidspunktet, hvor fejlen begyndte, og den præcise besked. Imens er der intet at ændre på hjemmesiden.

2. Er oplysningerne i wp-config.php korrekte?

Det er den hyppigste årsag efter en flytning af hjemmesiden, en ændring af databasens adgangskode i kontrolpanelet eller en gendannelse af en sikkerhedskopi. Sammenlign de fire værdier i wp-config.php med databaseafsnittet i dit kontrolpanel:

• DB_NAME og DB_USER: mange udbydere sætter kontonavnet foran (konto_wordpress). Præfikset er en del af navnet.
• DB_PASSWORD: er du i tvivl, så sæt en ny adgangskode for brugeren i kontrolpanelet, og kopiér den ind i filen.
• DB_HOST: localhost hos mange udbydere, men ikke alle. Nogle angiver et servernavn eller en adresse, nogle gange efterfulgt af en port (:3306). Den præcise værdi står i kontrolpanelet.
• Brugeren skal have rettigheder til databasen: tjek i kontrolpanelet, at brugeren er knyttet til databasen med alle privilegier.

En adgangskode med et enkelt anførselstegn (') afbryder PHP-strengen omkring den i wp-config.php. Sæt en omvendt skråstreg foran (\'), eller vælg en adgangskode uden enkelt anførselstegn.

Test oplysningerne uden for WordPress

WordPress viser en generel besked. MySQL siger derimod præcist, hvad der er galt. To måder at spørge den på, med værdierne fra wp-config.php:

Fra kommandolinjen, hvis du har SSH-adgang

mysql -h localhost -u brugernavn -p databasenavn

Med WP-CLI læser wp db check direkte wp-config.php og tjekker tabellerne med de oplysninger.

Med en midlertidig PHP-fil

Upload denne fil til hjemmesidens rodmappe under et navn, der er svært at gætte, åbn den i din browser, og slet den straks bagefter: den indeholder databasens adgangskode.

<?php
mysqli_report(MYSQLI_REPORT_OFF);
$forbindelse = @mysqli_connect('localhost', 'brugernavn', 'adgangskode', 'databasenavn');
echo $forbindelse ? 'Forbindelse OK' : 'Fejl: ' . mysqli_connect_error();

Den første linje er vigtig: siden PHP 8.1 udløser en mislykket forbindelse som standard en undtagelse, og siden ville forblive hvid i stedet for at vise beskeden fra MySQL.

3. En beskadiget database: reparationsværktøjet

Når oplysningerne er korrekte, men tabeller er beskadigede, viser den offentlige hjemmeside den samme forbindelsesfejl, og administrationen en mere præcis: «En eller flere databasetabeller er ikke tilgængelige. Databasen kan have brug for at blive repareret.» WordPress har et værktøj til det. Tilføj denne linje i wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Åbn derefter https://www.din-hjemmeside.com/wp-admin/maint/repair.php, og kør «Reparer database». Fjern linjen, så snart reparationen er færdig: så længe den står der, kan alle nå den side uden at logge ind.

Før enhver reparation eksporterer du databasen (wp db export eller eksportfunktionen i phpMyAdmin). Mislykkes reparationen, kan din udbyder gendanne databasen fra sine sikkerhedskopier.

4. En fejl, der kommer og går: belastningen

En fejl, der dukker op på bestemte tidspunkter og derefter forsvinder af sig selv, peger på en overbelastet server snarere end på en forkert indstilling. De almindelige årsager:

• En trafikspids, ofte bots: gentagne loginforsøg på wp-login.php eller xmlrpc.php, som kan ses i din udbyders adgangslogfiler.
• Grænserne på et delt webhotel: samtidige forbindelser eller processer begrænset pr. konto. Kontrolpaneler viser dem som regel i afsnittet om ressourceforbrug.
• Et tungt plugin: statistik, logfiler eller planlagte opgaver, der skriver til databasen ved hvert besøg.

Løsningerne: bloker misbrugende loginforsøg, tilføj sidecache, slå xmlrpc.php fra, hvis intet program bruger den, og bed din udbyder om logfilerne for tidspunktet, hvor fejlen opstod.