Vit skärm i WordPress: läs felet innan du ändrar något

”Kritiskt fel” eller vit skärm: samma haveri

En tom sida är nästan alltid ett fatalt PHP-fel: en fil på webbplatsen bad om något omöjligt, och körningen stannade innan något hann visas. Sedan WordPress 5.2 fångar WordPress de här felen: i stället för en tom sida visar det ”Det har uppstått ett kritiskt fel på webbplatsen.” och skickar ett mejl till webbplatsens administratörsadress.

Sidan förblir helt vit i några få fall: en äldre WordPress-version, ett fel som inträffar innan det här skyddsnätet har laddats, konstanten WP_DISABLE_FATAL_ERROR_HANDLER satt till true, eller ett cachetillägg som serverar en tom sida som det sparade under haveriet. Metoden nedan fungerar i alla dessa fall.

Tre åtgärder kan vänta tills du har läst felet: att installera om WordPress, att radera tillägg och att återställa en gammal säkerhetskopia. Var och en kan radera inställningar eller nya data, medan felmeddelandet oftast talar om exakt vilken komponent du ska stänga av, utan att något går förlorat.

Genvägen: räddningsläget

När WordPress fångar felet skickar det ett mejl till webbplatsens administratörsadress med ämnet ”[Webbplatsens namn] Din webbplats har råkat ut för ett tekniskt problem”. Det namnger tillägget eller temat som orsakar felet och innehåller en länk som öppnar adminpanelen i räddningsläge.

• I det här läget är den felande komponenten pausad för dig ensam: dina besökare ser fortfarande felet.
• Från Tillägg eller Utseende > Teman inaktiverar du komponenten som mejlet namnger och klickar sedan på ”Avsluta räddningsläget” i fältet högst upp på sidan.
• Länken gäller i 24 timmar, och WordPress skickar högst ett sådant mejl per dag. Kommer det inte fram, titta i skräpposten och gå sedan vidare till nästa metod.

Läs felet: felsökningsloggen

Anslut till webbplatsen via SFTP eller med webbhotellets filhanterare, öppna wp-config.php i rotmappen och ersätt raden define( 'WP_DEBUG', false ); med de här fyra raderna:

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

De ska stå ovanför raden /* That's all, stop editing! Happy publishing. */. Ladda om sidan som inte fungerar och öppna sedan wp-content/debug.log. Med WP_DEBUG_DISPLAY satt till false hamnar meddelandena i filen och inte på sidan som dina besökare ser.

Förblir debug.log tom eller dyker inte upp har PHP loggat felet självt: leta efter en fil som heter error_log i webbplatsens rotmapp eller i wp-admin, eller efter avsnittet med felloggar i webbhotellets kontrollpanel.

Vad meddelandet säger, och åtgärden som hör till

Ett fatalt fel ryms på en rad: feltypen, en beskrivning, sedan in följt av filens fullständiga sökväg och radnumret. Sökvägen är den mest användbara delen: wp-content/plugins/namn/ pekar på ett tillägg, wp-content/themes/namn/ på ett tema.

define( 'WP_MEMORY_LIMIT', '256M' );

Stäng av den felande komponenten utan adminpanelen

Via SFTP eller med filhanteraren

Byt namn på mappen för tillägget som meddelandet namnger, till exempel wp-content/plugins/tillaggets-namn till tillaggets-namn.off. WordPress hittar inte längre tillägget och slutar ladda det; dess inställningar ligger kvar i databasen, och WordPress inaktiverar det nästa gång sidan Tillägg öppnas.

För ett tema ger ett namnbyte på dess mapp i wp-content/themes tillbaka adminpanelen, men besökarna ser en tom sida så länge inget tema är aktivt. Öppna Utseende > Teman direkt: WordPress märker att det aktiva temat är trasigt och återgår till ett installerat standardtema.

Med WP-CLI

wp plugin list --status=active
wp plugin deactivate tillaggets-namn
wp theme list
wp theme activate twentytwentyfive

Det första kommandot noterar vilka tillägg som är aktiva, vilket är bra att ha innan en massinaktivering. Stannar WP-CLI självt på felet, lägg till --skip-plugins --skip-themes i kommandot så att det startar utan att ladda tilläggen eller temat. Tilläggen i wp-content/mu-plugins laddas ändå; kommer felet från ett av dem, byt namn på dess fil.

När meddelandet inte namnger någon komponent stänger wp plugin deactivate --all av alla tillägg. Kommer webbplatsen tillbaka, aktivera dem igen ett i taget och ladda om webbplatsen mellan varje: det sist återaktiverade innan felet återkommer är boven.

När webbplatsen är tillbaka

1. Sätt tillbaka define( 'WP_DEBUG', false ); och ta bort WP_DEBUG_LOG från wp-config.php.
2. Radera wp-content/debug.log: filen ligger i en mapp som nås från webben, vem som helst kan läsa den, och den innehåller sökvägar på servern.
3. Uppdatera eller byt ut den komponent som orsakade felet, efter att ha läst dess ändringslogg.
4. Töm cacheminnet i ditt cachetillägg, och webbhotellets cache om det har en.
5. Till nästa gång: testa uppdateringar på en kopia av webbplatsen innan du genomför dem skarpt.