Du klickade på ”Uppdatera” och några sekunder senare svarar sajten med vit skärm eller ”Det har uppstått ett kritiskt fel”. Det goda i det dåliga: när ett problem börjar precis efter en uppdatering har du en stark ledtråd. Nedan går vi metodiskt från symtom till bekräftad orsak.
1. Ta reda på vad som uppdaterades – och när
Börja med tidslinjen. Gå till Verktyg → Webbplatshälsa eller titta i Instrumentpanel → Uppdateringar. Om du har en aktivitetslogg (t.ex. WP Activity Log) ser du exakt vilket plugin som uppdaterades och när. Notera tidpunkten – den ska matcha när sajten slutade fungera. Ett fel som börjar minuter efter en uppdatering är starkt korrelerat med just den uppdateringen, även om du ännu inte bevisat det.
2. Slå på felsökningsloggen
WordPress döljer som standard fel för besökare. Öppna wp-config.php via FTP eller filhanteraren och lägg till, ovanför raden /* That's all, stop editing! */:
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );
Ladda om sidan som kraschar och öppna sedan wp-content/debug.log. Det är här sanningen finns.
3. Läs det fatala felet och stack-tracen
Ett typiskt PHP-fatalt fel ser ut så här:
PHP Fatal error: Uncaught Error: Call to undefined function acme_helper() in /wp-content/plugins/acme-forms/includes/render.php:212
Sista raden pekar på filen och plugin-mappen där felet kastades. Följs det av en Stack trace kan du läsa anropskedjan bakåt. För ett rent PHP-fatalt fel är plugin-mappen i sökvägen (här acme-forms) platsen där koden brast – din huvudmisstänkte, och det första du testar i steg 5.
När felet pekar på ett annat plugin än det du uppdaterade
Ibland uppdaterade du plugin A men tracen pekar på plugin B. Det beror ofta på en beroendekonflikt – A tog bort eller ändrade en funktion som B förlitade sig på. Börja ändå med det som just ändrades.
Utelåst? WordPress kan redan ha mejlat dig
Sedan WordPress 5.2 skickar ett fatalt fel ett mejl till administratörsadressen (”Din webbplats har ett tekniskt problem”) med en länk till återställningsläget. Den loggar in dig i wp-admin med det felande pluginet pausat, så att du kan rulla tillbaka det under Instrumentpanel → Uppdateringar utan FTP. Inget mejl? Då saknar sajten kanske fungerande e-postutskick – att döpa om mappen, som nedan, fungerar alltid.
4. Rulla tillbaka det skyldiga pluginet
Har du inte adminpanelen? Byt namn på pluginets mapp via FTP, t.ex. acme-forms till acme-forms.off. WordPress avaktiverar det automatiskt och du kommer förmodligen in i wp-admin igen. Installera sedan en tidigare version med pluginet WP Rollback, eller ladda ner den från fliken ”Advanced View” på pluginets sida i wordpress.org och installera manuellt.
5. Bekräfta att det var orsaken
Ladda om sajten. Fungerar den nu med det återställda pluginet är orsaken bekräftad. Rensa alla cachar först – sidcache, objektcache och eventuell CDN-cache – så att du inte tittar på en gammal version. Kontrollera också att din PHP-version stöds av den nya pluginversionen; många fatala fel efter uppdatering beror på att pluginet kräver nyare PHP än servern kör.
När pluginet inte är hela förklaringen
Kommer sajten inte tillbaka efter återställningen, titta på vad uppdateringen ändrade runt pluginet:
- Minne.
Allowed memory size of … bytes exhaustedbetyder att den nya versionen behöver mer minne. HöjWP_MEMORY_LIMITi wp-config.php (till exempel till256M); har webbhotellet ett tak höjer du det i php.ini eller kontrollpanelen. - PHP-version. Ett plugin som nu kräver PHP 8.1 på en server med 7.4 – eller ett gammalt plugin som möter en nyare PHP – faller på samma sätt. Kontrollera under Verktyg → Webbplatshälsa → Info → Server, och testa ett PHP-byte i staging först.
- Objektcache. Ett inaktuellt eller trasigt objektcache-tillägg kan fortsätta servera felet även när det egentliga problemet är borta. Töm cachen, eller stäng av den en stund, innan du drar några slutsatser.
6. Åtgärda ordentligt
En tillbakarullning är en tillfällig lösning. Läs pluginets ändringslogg, testa den nya versionen i en staging-miljö, och rapportera buggen till utvecklaren. När en fix släppts uppdaterar du igen – den här gången först i staging.
När ”vad ändrades precis innan” ska vara direkt tillgängligt
Hela den här jakten handlar om en enda fråga: vad hände precis innan det gick sönder? Det är just där Ravnsights Detective sparar tid. Detective loggar varje plugin-, tema- och core-uppdatering, grupperar det PH‑fatala felet och kopplar det till pluginet som stack-tracen pekar på – allt på en och samma tidslinje. I stället för att manuellt korsa aktivitetsloggar mot debug.log ser du direkt att ”felet började tre sekunder efter att acme-forms uppdaterades”.
Och eftersom en kraschad sajt inte alltid loggar åt sig själv – om PHP dör tidigt skrivs kanske inget till debug.log – är det värt att övervaka utifrån också. Ravnsights upptidsbevakning märker nedtiden från en extern punkt och larmar dig innan en kund hinner göra det, så att du kan börja felsöka minuter efter – inte timmar efter – att uppdateringen slår fel.
