Nettstedet falt til et tomt hvitt tomrom med én enkelt linje: «Feil ved etablering av databasetilkobling.» Ikke få panikk. Dette er ikke et hack, og det er ikke databasedød. Ni av ti ganger er problemet løst på fem minutter.

I praksis opplever alle WordPress-eiere denne feilen på et tidspunkt. Årsaken er nesten alltid triviell: et feil passord i wp-config.php, en krasjet MySQL-server eller en korrupt tabell etter en mislykket plugin-oppdatering.

Nedenfor finner du fire velprøvde måter å bringe nettstedet tilbake til live, fra den vanligste løsningen til siste utvei. Før du rører databasen, ta en sikkerhetskopi.

💡 Rask oversikt:

• Sjekk MySQL-påloggingsinformasjonen i wp-config.php (den vanligste synderen)
• Kjør det innebygde database-reparasjonsverktøyet via WP_ALLOW_REPAIR
• Erstatt korrupte WordPress-kjernefiler med en fersk kopi
• Hvis ingenting fungerer, gjenopprett nettstedet fra en sikkerhetskopi

Hvorfor feilen med databasetilkobling oppstår

WordPress lagrer alt innhold (innlegg, sider, innstillinger, brukere) i en MySQL-database. Når en nettleser ber om en side, spør WordPress sin PHP-kjerne databasen, henter dataene og setter sammen HTML. Hvis koblingen mellom kjernen og databasen brytes, ser du en hvit skjerm med en feilmelding.

Det er fire årsaker til bruddet:

• Feil påloggingsinformasjon. Brukernavnet, passordet eller databaseverten i wp-config.php samsvarer ikke med de faktiske verdiene. Dette skjer etter migrering til en annen vert eller tilbakestilling av MySQL-passordet.
• Databasen er nede. MySQL-serveren hos verten har stoppet på grunn av overbelastning, vedlikehold eller overskredne grenser.
• Korrupte tabeller. En plugin eller et tema har skadet systemtabeller under installasjon eller fjerning. Dette er vanlig med hurtigbuffer- og optimaliseringsplugins.
• Ødelagte kjernefiler. En ufullstendig FTP-overføring, en mislykket automatisk WordPress-oppdatering eller ondsinnet kode.

Vi identifiserer den spesifikke årsaken steg for steg, fra den mest sannsynlige til den minst sannsynlige.

Steg 1: Sjekk påloggingsinformasjonen i wp-config.php

Start med den enkleste løsningen. Filen wp-config.php ligger i nettstedets rot og inneholder fire nøkkellinjer for tilkobling til databasen:

1
define('DB_NAME', 'database_name');
2
define('DB_USER', 'username');
3
define('DB_PASSWORD', 'password');
4
define('DB_HOST', 'localhost');

Åpne filen via vertens filbehandler eller via FTP og sammenlign hver verdi med de som vises i vertskontrollpanelet under «MySQL-databaser» eller phpMyAdmin.

Vær oppmerksom på DB_HOST. De fleste verter bruker localhost, men noen (spesielt sky- og klyngeoppsett) oppgir en separat IP-adresse eller et databaseserverdomene. Hvis du nylig byttet abonnement eller vert, sjekk denne parameteren først.

Etter å ha endret verdier, lagre filen og oppdater nettstedet. Fungerer det? Flott. Hvis ikke, gå videre.

Steg 2: Reparer databasen med WP_ALLOW_REPAIR

WordPress kan reparere sine egne tabeller; du trenger bare å aktivere det innebygde reparasjonsverktøyet. Legg til én linje i wp-config.php før /* That's all, stop editing! */:

1
define('WP_ALLOW_REPAIR', true);

Gå nå til:

1
https://your-site.com/wp-admin/maint/repair.php

Du ser en side med to knapper: «Repair Database» og «Repair and Optimize Database». Den første reparerer bare tabeller; den andre optimaliserer dem også. For en rask løsning er den første knappen nok.

Etter at prosessen er ferdig, *sørg for å fjerne WP_ALLOW_REPAIR-linjen fra wp-config.php*. Hvis du lar den stå, kan alle som oppdager repair.php-URL-en kjøre reparasjoner uten autentisering.

I praksis løser denne metoden omtrent en tredjedel av tilkoblingsfeilene. Hvis det ikke hjalp, gå videre til kjernefilene.

Hvis du foretrekker å se prosessen visuelt, demonstrerer videoen ovenfor hvert steg i sanntid, fra diagnostikk til gjenoppretting.

Steg 3: Erstatt korrupte WordPress-kjernefiler

Ødelagte kjernefiler er en annen vanlig årsak. De blir korrupte når en FTP-tilkobling faller ut, en automatisk oppdatering mislykkes, eller ondsinnede skript tukler med dem.

Erstatningstrinn:

• Last ned det nyeste WordPress-arkivet fra det offisielle nettstedet.
• Pakk ut arkivet på datamaskinen din.
• Slett mappen wp-content og filen wp-config-sample.php fra den utpakkede mappen. Du trenger ikke å laste opp disse; ellers overskriver du dine temaer, plugins og opplastinger.
• Last opp de gjenværende filene og mappene til serveren via FTP eller vertens filbehandler, og erstatt eksisterende filer.

Kjernen er nå oppdatert, og innholdet og innstillingene dine forblir urørte: de ligger i wp-content og databasen, som du ikke endret. Tøm nettleserens hurtigbuffer før du tester; hurtigbufrede gamle skript maskerer noen ganger en vellykket gjenoppretting.

Steg 4: Gjenopprett nettstedet fra en sikkerhetskopi

Hvis de tre foregående stegene ikke ga noe resultat, stikker problemet dypere enn det ser ut til. Skaden er ikke begrenset til enkeltfiler eller tabeller; selve databasestrukturen er kompromittert. Den eneste pålitelige løsningen er å rulle tilbake til det siste fungerende tidspunktet.

Nøyaktig hvordan du gjenoppretter avhenger av hva du brukte til sikkerhetskopiering. Vi dekket alle metoder i detalj i en egen artikkel: hvordan gjenopprette WordPress fra en sikkerhetskopi, via cPanel, FTP, en plugin eller phpMyAdmin.

Å rulle tilbake til en sikkerhetskopi vil angre nylige endringer på nettstedet: nye innlegg, plugin-innstillinger, temabytter. Men det er bedre enn et dødt nettsted som ikke vil laste.

⁉️🤔 Ofte stilte spørsmål

Hvorfor vises feilen bare noen ganger, ikke konstant?

Mest sannsynlig begrenser vertsleverandøren antall samtidige MySQL-tilkoblinger, og databasen blir midlertidig utilgjengelig under trafikktopper. Sjekk grensene i vertsabonnementet ditt. På delt hosting er løsningen vanligvis å oppgradere til en VPS.

Kan jeg reparere databasen via phpMyAdmin uten å røre wp-config.php?

Ja. Logg inn på phpMyAdmin via vertspanelet, velg nettstedets database, kryss av for alle tabeller og velg «Repair table» fra nedtrekksmenyen «With selected». Dette tilsvarer WP_ALLOW_REPAIR, men uten å redigere kode.

Hjelper det å bytte til et standardtema ved en feil med databasetilkobling?

Nei. Feilen oppstår på tilkoblingsnivået mellom PHP og MySQL; temaer er urelaterte. Å bytte tema løser visningsproblemer, ikke tilkoblingsproblemer.

Hva bør jeg gjøre hvis databasen er uopprettelig skadet?

Hvis WP_ALLOW_REPAIR og phpMyAdmin ikke kan fikse det, kontakt vertens support. De fleste leverandører oppbevarer automatiske serversikkerhetskopier for de siste 3-7 dagene. Å gjenopprette fra en slik sikkerhetskopi er en sak om én supportsak.

Kan en sikkerhetsplugin forårsake denne feilen?

Ja. Noen sikkerhetsplugins endrer tabellprefikset (fra wp_ til noe tilfeldig) eller blokkerer eksterne databasetilkoblinger. Hvis feilen dukket opp rett etter installasjon av en slik plugin, gi mappen dens et midlertidig nytt navn via FTP og test nettstedet.

Nettstedet puster igjen: hva du bør huske for fremtiden

Feilsøkingsrekkefølgen for «Feil ved etablering av en databasetilkobling» går alltid fra enkelt til komplekst. Halvparten av tiden er det første steget nok: åpne wp-config.php, fiks passordet, så kommer nettstedet tilbake til live.

Sett opp automatiske sikkerhetskopier hvis du ikke allerede har gjort det. Den gratis plugin-en UpdraftPlus sikkerhetskopierer databasen og filene til skyen (Google Drive, Dropbox eller hvor du måtte ønske) én gang om dagen. Med en sikkerhetskopi blir ethvert WordPress-problem forvandlet fra en katastrofe til et ti-minutters ubeleilighet. Velprøvd.