Webbplatsen försvann och ersattes av en tom vit sida med en enda rad: "Error establishing a database connection." Ingen panik. Det här är inte en hackning och inte en död databas. I nio fall av tio är problemet löst på fem minuter.

I praktiken stöter alla som äger en WordPress-sajt på det här felet förr eller senare. Orsaken är nästan alltid banal: ett felaktigt lösenord i wp-config.php, en kraschad MySQL-server eller en trasig tabell efter en misslyckad plugin-uppdatering.

Här är fyra beprövade sätt att få liv i sajten igen, från den vanligaste lösningen till den sista utvägen. Gör en säkerhetskopia innan du rör databasen.

💡 Snabb överblick:

• Kontrollera MySQL-uppgifterna i wp-config.php (den vanligaste boven)
• Kör det inbyggda databasreparationsverktyget via WP_ALLOW_REPAIR
• Ersätt skadade WordPress-kärnfiler med en ny kopia
• Om inget fungerar, återställ sajten från en säkerhetskopia

Varför felet med databasanslutningen uppstår

WordPress lagrar allt innehåll (inlägg, sidor, inställningar, användare) i en MySQL-databas. När en webbläsare begär en sida frågar WordPress PHP-kärna databasen, hämtar data och bygger HTML. Om länken mellan kärnan och databasen bryts ser du en vit skärm med ett felmeddelande.

Det finns fyra orsaker till brottet:

• Felaktiga inloggningsuppgifter. Användarnamnet, lösenordet eller databasvärden i wp-config.php stämmer inte överens med de faktiska värdena. Detta händer efter migrering till en annan host eller efter återställning av MySQL-lösenordet.
• Databasen ligger nere. MySQL-servern hos webbhotellet har stoppats på grund av överbelastning, underhåll eller överskridna gränser.
• Trasiga tabeller. En plugin eller ett tema har skadat systemtabeller under installation eller borttagning. Detta är vanligt med caching- och optimeringsplugins.
• Skadade kärnfiler. En ofullständig FTP-överföring, en misslyckad automatisk WordPress-uppdatering eller skadlig kod.

Vi identifierar den specifika orsaken steg för steg, från den mest sannolika till den minst sannolika.

Steg 1: Kontrollera inloggningsuppgifterna i wp-config.php

Börja med den enklaste lösningen. Filen wp-config.php ligger i sajtens rot och innehåller fyra nyckelrader för att ansluta till databasen:

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

Öppna filen via ditt webbhotells filhanterare eller via FTP och jämför varje värde med de som visas i kontrollpanelen för webbhotellet under "MySQL-databaser" eller phpMyAdmin.

Var uppmärksam på DB_HOST. De flesta webbhotell använder localhost, men vissa (särskilt moln- och klusterlösningar) tillhandahåller en separat IP-adress eller en databasserverdomän. Om du nyligen bytte abonnemang eller webbhotell, kontrollera den här parametern först.

Spara filen och uppdatera sajten efter att du har ändrat värden. Fungerar det? Utmärkt. Om inte, gå vidare.

Steg 2: Reparera databasen med WP_ALLOW_REPAIR

WordPress kan fixa sina egna tabeller; du behöver bara aktivera det inbyggda reparationsverktyget. Lägg till en rad i wp-config.php före /* That's all, stop editing! */:

1
define('WP_ALLOW_REPAIR', true);

Gå nu till:

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

Du ser en sida med två knappar: "Repair Database" och "Repair and Optimize Database." Den första reparerar bara tabeller; den andra optimerar dem också. För en snabb lösning räcker den första knappen.

När processen är klar, se till att ta bort raden med WP_ALLOW_REPAIR från wp-config.php. Om du låter den vara kvar kan vem som helst som upptäcker repair.php-URL:en köra reparationer utan autentisering.

I praktiken löser den här metoden ungefär en tredjedel av anslutningsfelen. Om det inte hjälpte, gå vidare till kärnfilerna.

Om du föredrar att se processen visuellt visar videon ovan varje steg i realtid, från diagnostik till återställning.

Steg 3: Ersätt skadade WordPress-kärnfiler

Skadade kärnfiler är en annan vanlig orsak. De blir korrupta när en FTP-anslutning bryts, en automatisk uppdatering misslyckas eller skadliga skript manipulerar dem.

Ersättningssteg:

• Ladda ner det senaste WordPress-arkivet från den officiella webbplatsen.
• Packa upp arkivet på din dator.
• Ta bort mappen wp-content och filen wp-config-sample.php från den uppackade mappen. Du behöver inte ladda upp dessa; annars skriver du över dina teman, plugins och uppladdningar.
• Ladda upp de återstående filerna och mapparna till servern via FTP eller ditt webbhotells filhanterare och ersätt befintliga filer.

Kärnan är nu uppdaterad och ditt innehåll och dina inställningar förblir orörda: de finns i wp-content och databasen, som du inte har ändrat. Rensa webbläsarens cache innan du testar; cachade gamla skript kan ibland dölja en lyckad återställning.

Steg 4: Återställ sajten från en säkerhetskopia

Om de tre föregående stegen inte gav något resultat är problemet djupare än det verkar. Skadan är inte begränsad till enskilda filer eller tabeller; själva databasstrukturen är komprometterad. Den enda pålitliga lösningen är att rulla tillbaka till den senaste fungerande tidpunkten.

Exakt hur du återställer beror på vad du använde för säkerhetskopiering. Vi har täckt alla metoder i detalj i en separat artikel: hur man återställer WordPress från en säkerhetskopia, via cPanel, FTP, en plugin eller phpMyAdmin.

Att rulla tillbaka till en säkerhetskopia kommer att ångra nyliga ändringar på sajten: nya inlägg, plugin-inställningar, temabyten. Men det är bättre än en död sajt som inte laddar.

⁉️🤔 Vanliga frågor

Varför visas felet bara ibland, inte konstant?

Troligtvis begränsar webbhotellet antalet samtidiga MySQL-anslutningar och databasen blir tillfälligt otillgänglig under trafiktoppar. Kontrollera gränserna i ditt webbhotellsabonnemang. På delade webbhotell är lösningen oftast att uppgradera till en VPS.

Kan jag reparera databasen via phpMyAdmin utan att röra wp-config.php?

Ja. Logga in i phpMyAdmin via webbhotellets kontrollpanel, välj sajtens databas, markera alla tabeller och välj "Repair table" från rullgardinsmenyn "With selected". Detta motsvarar WP_ALLOW_REPAIR, men utan att redigera kod.

Hjälper det att byta till ett standardtema vid ett databasanslutningsfel?

Nej. Felet uppstår på anslutningsnivån mellan PHP och MySQL; teman är orelaterade. Att byta tema löser visningsproblem, inte anslutningsproblem.

Vad ska jag göra om databasen är oåterkalleligt skadad?

Om WP_ALLOW_REPAIR och phpMyAdmin inte kan fixa den, kontakta ditt webbhotells support. De flesta leverantörer sparar automatiska serverbackuper för de senaste 3-7 dagarna. Att återställa från en sådan säkerhetskopia är en fråga om ett supportärende.

Kan en säkerhetsplugin orsaka det här felet?

Ja. Vissa säkerhetsplugins ändrar tabellprefixet (från wp_ till något slumpmässigt) eller blockerar externa databasanslutningar. Om felet dök upp direkt efter installation av en sådan plugin, byt tillfälligt namn på dess mapp via FTP och testa sajten.

Sajten andas igen: vad du ska komma ihåg för framtiden

Felsökningsordningen för "Error establishing a database connection" går alltid från enkel till komplex. Hälften av gångerna räcker det första steget: öppna wp-config.php, fixa lösenordet så kommer sajten tillbaka till liv.

Ställ in automatiska säkerhetskopior om du inte redan har gjort det. Den kostnadsfria pluginen UpdraftPlus säkerhetskopierar databasen och filerna till molnet (Google Drive, Dropbox eller vart du vill) en gång om dagen. Med en säkerhetskopia förvandlas varje WordPress-fel från en katastrof till ett tio minuters besvär. Beprövat.