Hvid skærm i WordPress: læs fejlen, før du ændrer noget

«Kritisk fejl» eller hvid skærm: den samme fejl

En tom side er næsten altid en fatal PHP-fejl: en fil på hjemmesiden bad om noget umuligt, og kørslen stoppede, før noget blev vist. Siden WordPress 5.2 fanger WordPress disse fejl: i stedet for en tom side viser det «Der er sket en kritisk fejl på dit websted.» og sender en mail til hjemmesidens administrationsadresse.

Siden forbliver helt hvid i nogle få tilfælde: en ældre WordPress-version, en fejl, der opstår, før dette sikkerhedsnet er indlæst, konstanten WP_DISABLE_FATAL_ERROR_HANDLER sat til true, eller et cacheplugin, der serverer en tom side, som det gemte under fejlen. Metoden nedenfor virker i alle tilfældene.

Tre indgreb kan vente, til du har læst fejlen: at geninstallere WordPress, at slette plugins og at gendanne en gammel sikkerhedskopi. Hver af dem kan slette indstillinger eller nyere data, mens fejlbeskeden som regel fortæller dig præcis, hvilken komponent du skal slå fra, uden at noget går tabt.

Genvejen: gendannelsestilstand

Når WordPress fanger fejlen, sender det en mail til hjemmesidens administrationsadresse med emnet «[Webstedets navn] Dit websted har et teknisk problem». Den nævner det plugin eller tema, der er skyld i fejlen, og indeholder et link, der åbner administrationen i gendannelsestilstand.

• I denne tilstand er den fejlende komponent sat på pause for dig alene: dine besøgende ser stadig fejlen.
• Fra Plugins eller Udseende > Temaer deaktiverer du den komponent, mailen nævner, og klikker derefter på «Luk gendannelsestilstand» i administrationslinjen.
• Linket er gyldigt i 24 timer, og WordPress sender højst én sådan mail om dagen. Kommer den ikke, så tjek spammappen, og gå derefter videre til den næste metode.

Læs fejlen: fejlfindingsloggen

Forbind dig til hjemmesiden via SFTP eller med din udbyders filhåndtering, åbn wp-config.php i rodmappen, og erstat linjen define( 'WP_DEBUG', false ); med disse fire linjer:

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

De skal stå over linjen /* That's all, stop editing! Happy publishing. */. Genindlæs den side, der fejler, og åbn derefter wp-content/debug.log. WP_DEBUG_DISPLAY sat til false holder beskederne i filen og væk fra den side, dine besøgende ser.

Forbliver debug.log tom, eller dukker den ikke op, har PHP selv logget fejlen: led efter en fil ved navn error_log i hjemmesidens rodmappe eller i wp-admin, eller efter afsnittet med fejllogfiler i din udbyders kontrolpanel.

Det, beskeden siger, og løsningen, der hører til

En fatal fejl fylder én linje: fejltypen, dens beskrivelse, derefter in efterfulgt af den fulde filsti og linjenummeret. Stien er den mest nyttige del: wp-content/plugins/navn/ peger på et plugin, wp-content/themes/navn/ på et tema.

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

Slå den fejlende komponent fra uden administrationen

Via SFTP eller med filhåndteringen

Omdøb mappen for det plugin, beskeden nævner, for eksempel wp-content/plugins/plugin-navn til plugin-navn.off. WordPress finder ikke længere pluginet og holder op med at indlæse det; dets indstillinger forbliver gemt i databasen, og WordPress deaktiverer det, næste gang skærmen Plugins åbnes.

For et tema giver en omdøbning af mappen i wp-content/themes dig administrationen tilbage, men de besøgende ser en tom side, så længe intet tema er aktivt. Åbn straks Udseende > Temaer: WordPress opdager, at det aktive tema er defekt, og skifter tilbage til et installeret standardtema.

Med WP-CLI

wp plugin list --status=active
wp plugin deactivate plugin-navn
wp theme list
wp theme activate twentytwentyfive

Den første kommando noterer, hvilke plugins der er aktive, og den liste er god at have før enhver samlet deaktivering. Stopper WP-CLI selv på fejlen, så tilføj --skip-plugins --skip-themes til kommandoen: så starter den uden at indlæse plugins eller temaet. Plugins i wp-content/mu-plugins indlæses alligevel; kommer fejlen fra et af dem, så omdøb dets fil.

Når beskeden ikke nævner nogen komponent, slår wp plugin deactivate --all alle plugins fra. Kommer hjemmesiden tilbage, så genaktiver dem ét ad gangen, og genindlæs hjemmesiden imellem: det sidste plugin, du genaktiverede, før fejlen vendte tilbage, er synderen.

Når hjemmesiden er tilbage

1. Sæt define( 'WP_DEBUG', false ); igen, og fjern WP_DEBUG_LOG fra wp-config.php.
2. Slet wp-content/debug.log: filen ligger i en mappe, der kan nås fra nettet, så alle kan læse den, og den indeholder stier på serveren.
3. Opdater eller udskift den komponent, der var skyld i fejlen, efter at have læst dens ændringslog.
4. Ryd cachen i dit cacheplugin, og hos din udbyder, hvis den har en cache.
5. Til næste gang: test opdateringer på en kopi af hjemmesiden, før du lægger dem på den rigtige.