Min WordPress-hemsida visar ett kritiskt fel. Hur felsöker jag?

Avancerad guide

Visar hemsidan ett meddelande om ett kritiskt fel, en vit sida eller ett serverfel? Det kan bero på ett tillägg, ett äldre tema, en PHP-version som inte passar webbplatsens kod eller ett problem på servern.

Här går vi igenom hur en teknisk felsökning kan gå till. Du behöver tillgång till webbplatsens filer och vara bekväm med att redigera konfigurationsfiler.

Vill du ha hjälp direkt? Kontakta ola@brandstedt.net eller ring 073-370 83 45. Om vi sköter ditt webbhotell behöver du inte ordna filåtkomst själv.

1. Dokumentera felet innan du ändrar något

Börja med att anteckna:

• Det exakta felmeddelandet och vilken sida det visas på.
• När problemet började.
• Om WordPress, något tillägg, temat eller PHP nyligen uppdaterades.
• Om även administrationen är otillgänglig.
• Om felet gäller hela webbplatsen eller en viss funktion.

Ett fel som uppstod direkt efter en förändring ger en ledtråd, men behöver undersökas innan orsaken är fastställd.

Kontrollera också om WordPress har skickat ett mejl till administratören med en länk till återställningsläget, Recovery Mode. Det kan ibland ge tillgång till administrationen trots ett fel i ett tillägg eller tema. WordPress om återställningsläget.

2. Säkerhetskopiera och förbered återställning

Innan du ändrar filer behöver du en säkerhetskopia av både filer och databas, samt veta hur den återställs. Behåll även en tidigare fungerande backup.

Gör helst felsökningen på en testkopia. På en aktiv webbplats kan avstängda tillägg påverka formulär, betalningar, bokningar och andra funktioner.

För en webbutik behöver återställning planeras särskilt noggrant så att nya beställningar inte skrivs över av en äldre databas.

3. Anslut till rätt WordPress-installation

Använd webbhotellets filhanterare eller en krypterad filanslutning, exempelvis SFTP eller FTPS om webbhotellet stöder det.

I WordPress-installationen finns normalt:

wp-admin/
wp-content/
wp-includes/
wp-config.php

Kontrollera att du arbetar med rätt domän och rätt installation. Ladda ned en kopia av wp-config.php innan du redigerar den. Filen innehåller känsliga uppgifter och ska inte delas offentligt.

4. Aktivera tillfällig felloggning

I wp-config.php kan följande inställningar användas:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ändra befintliga definitioner om de redan finns. Lägg inte in samma konstant flera gånger. Inställningarna ska ligga före raden med kommentaren ”That’s all, stop editing!”.

Detta aktiverar loggning utan att avsiktligt visa felinformationen för besökarna. Värdena true och false skrivs utan citationstecken.

Återskapa sedan felet och kontrollera normalt:

wp-content/debug.log

Loggen kan innehålla känsliga uppgifter. Den ska skyddas mot åtkomst via webben; en loggplats utanför den publika webbkatalogen är ett alternativ som kräver rätt serversökväg och skrivrättigheter.

WordPress rekommenderar felsökning på en testmiljö. På en skarp webbplats bör eventuell loggning vara kortvarig och kontrollerad. WordPress dokumentation om debug.

5. Läs rätt fel i loggen

Börja med posterna från tidpunkten då du återskapade problemet.

En sökväg som innehåller:

wp-content/plugins/exempel-plugin/

pekar mot ett tillägg. En sökväg under wp-content/themes/ pekar mot ett tema.

Sökvägen visar var felet uppstår, men inte alltid grundorsaken. Ett tillägg kan exempelvis anropa en funktion från ett annat tillägg som saknas eller har ändrats. Även anropskedjan, ofta kallad stack trace, kan behöva granskas.

6. Isolera det misstänkta tillägget

Om loggen pekar mot ett visst tillägg och administrationen inte fungerar kan du tillfälligt hindra tillägget från att laddas genom att byta namn på dess mapp.

Exempel:

wp-content/plugins/exempel-plugin

ändras till:

wp-content/plugins/exempel-plugin.avstangt

Ladda sedan om sidan och kontrollera om samma fel återkommer.

• Sidan fungerar: tillägget eller dess samspel med annan kod behöver undersökas.
• Felet kvarstår: kontrollera den nya loggposten. Det kan finnas fler fel eller en annan grundorsak.

Ändra en sak i taget och anteckna originalnamnen. Radera inte tilläggens filer som felsökningsmetod.

Om inget enskilt tillägg kan identifieras går det att tillfälligt byta namn på hela plugins-mappen. Det är ett bredare test som slår ut vanliga tillägg och deras funktioner. WordPress beskriver hur man därefter besöker administrationssidan för tillägg, återställer mappnamnet och återaktiverar tilläggen kontrollerat. WordPress felsökningsinstruktioner.

Observera att så kallade must-use plugins och vissa cachekomponenter inte stängs av genom detta test.

7. Kontrollera PHP-version och äldre teman

Ett äldre tillägg eller tema kan innehålla kod som inte fungerar med en nyare PHP-version. Samtidigt kan moderna tillägg kräva en nyare version än den webbhotellet använder.

Kontrollera därför kombinationen av:

• WordPress-version.
• PHP-version och nödvändiga PHP-tillägg.
• Aktivt tema, eventuellt barntema och egen kod.
• Installerade tillägg och deras beroenden.

Om felet började efter ett PHP-byte är det en viktig ledtråd. Att permanent gå tillbaka till en version som saknar säkerhetsstöd är däremot ingen hållbar lösning. Koden kan behöva uppdateras eller ersättas. WordPress om PHP och kompatibilitet.

Vid misstanke om temafel kan ett kontrollerat byte till ett installerat, kompatibelt standardtema göras på testkopian. Det kan förändra både utseende och funktioner. Byt inte bara namn på det aktiva temats mapp utan att ha en fungerande reservlösning.

8. Om ingen användbar debuglogg skapas

Alla fel inträffar inte inne i WordPress. Då kan webbhotellets PHP- och serverloggar behövas.

Exempel på andra orsaker är databasproblem, felaktiga filrättigheter, full lagring, serverkonfiguration eller resursgränser. Ett serverfel som 500, 502 eller 503 bevisar inte i sig att ett tillägg är trasigt.

Att bara höja minnesgränsen eller stänga av fler tillägg kan dölja symtom utan att lösa grundproblemet.

9. Kontrollera hela webbplatsen och avsluta felsökningen

När sidan öppnas igen återstår kontrollen av viktiga funktioner:

• Inloggning och administration.
• Formulär och faktisk mejlleverans.
• Mobilvisning, menyer och knappar.
• Bokning, varukorg och betalning där det är relevant.
• Bakgrundsjobb och integrationer.

Återställ avsedda mappnamn och aktivera endast de tillägg som ska användas, när orsaken är åtgärdad. Stäng av den tillfälliga debugloggningen, hantera loggfilerna säkert och dokumentera förändringarna.

En hemsida som startar igen är inte alltid färdiglagad.

Vill du att vi tar hand om felsökningen?

Skicka webbplatsens adress, felmeddelandet och vad som ändrades innan problemet började till ola@brandstedt.net.

Vi hjälper dig att läsa loggarna, undersöka tillägg och teman, kontrollera PHP-kompatibilitet och hitta en fungerande lösning. Om vi behöver åtkomst kommer vi överens om hur den lämnas. Skicka inga lösenord eller hela konfigurationsfiler i det första mejlet.

Läs mer om support och felsökning.