Mindre er mere: oprydning og konfliktløsning

Modul 5: Temaer og plugins · Læsetid: 9 minutter

Læringsmål: Efter denne lektion kan du rydde op i plugins og selv opspore og løse en konflikt eller en hvid side.

Nøglebegreber: deaktivere vs. slette, inaktiv kode, kritisk fejl, gendannelsestilstand (recovery mode), Webstedshelbred, fejlfindingstilstand, omdøbe pluginmappe, WP_DEBUG, WP_DEBUG_LOG, debug.log, fejllog

At slukke er ikke at smide væk

Under Plugins kan du deaktivere eller slette en plugin. Forskellen:

• Deaktiver: WordPress indlæser ikke længere pluginnet. Men filerne bliver stadig liggende i wp-content/plugins/, og kan ofte stadig hentes direkte via webserveren. Er der et hul i en enkelt PHP-fil i det plugin, er hullet der stadig. Indbrudsforsøg scanner efter kendte sårbare filer, ikke efter aktive plugins.
• Slet: filerne fjernes. Nogle plugins rydder også op i deres indstillinger og tabeller i databasen, når de slettes; andre lader dem blive stående.

Bruger du ikke længere en plugin, så slet den. Deaktivering er kun til midlertidig brug (mens du leder efter et problem). Det samme gælder for temaer (lektion 2.4).

Oprydning: en fast runde

Gennemgå dine plugins én gang i kvartalet (lektion 9.4). For hver plugin:

1. Hvad bruges den til? Ved du det ikke længere, find ud af det. Ofte viser det sig, at en plugin engang blev installeret til én ting og aldrig fjernet igen.
2. Bliver den stadig brugt? Et slider-plugin selvom der ikke findes en slider nogen steder, et formular-plugin selvom din kontaktside bruger en anden formular.
3. Kan det undværes? Kan WordPress, temaet eller et andet plugin allerede klare det (lektion 5.3)?
4. Vedligeholdes den stadig? Senest opdateret, stadig i pluginmappen?

Gør oprydningen først i et testmiljø (staging) (lektion 8.3), eller tag mindst en backup, og slet én plugin ad gangen, så du ved hvad der gik galt, hvis noget går galt. Pas på shortcodes: sletter du en plugin der leverede [formulier id="2"], så står den tekst bagefter bogstaveligt på din side.

Når det går galt: den kritiske fejl

Efter en opdatering, en ny plugin eller en PHP-opgradering ser du pludselig:

Der er sket en kritisk fejl på dit websted.

eller en helt hvid side. Det betyder: PHP er stoppet med en fatal fejl, før der var en side (lektion 1.2). Som regel skyldes det en plugin eller et tema, der ikke harmonerer med noget andet: en anden plugin, den nye version af WordPress, eller PHP-versionen.

Siden WordPress 5.2 gør WordPress to ting i så fald:

• det sender en e-mail til administratoradressen med oplysning om hvilken plugin eller hvilket tema der gav fejlen, og et særligt link;
• med det link logger du ind i gendannelsestilstand (recovery mode): kontrolpanelet virker så, med den plugin der gav fejlen midlertidigt slået fra, så du kan opdatere, udskifte eller slette den.

Derfor er en administratoradresse som du læser så vigtig (lektion 2.2).

Selv finde det: trinnene

Kommer der ingen mail, eller virker gendannelsestilstanden ikke? Sådan finder du det selv.

1. Kig i fejlloggen

Fejlen står næsten altid i webserverens eller PHP's fejllog. I DirectAdmin finder du den under logfilerne for dit domæne. Du leder efter en linje med PHP Fatal error og tidspunktet for dit forsøg:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

Stien fortæller dig hvem synderen er: her pluginnet i mappen oude-slider. Resten af linjen fortæller hvorfor (her: en funktion der er fjernet i PHP 8, lektion 8.4).

2. Slå debug-loggen til (ikke skærmvisningen)

Står der intet brugbart i fejlloggen, så sæt følgende i wp-config.php (over "stop med at redigere"):

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

WordPress skriver så alle fejl til wp-content/debug.log, uden at vise dem til besøgende. Lad aldrig dette stå slået til længere end nødvendigt: debug.log ligger i en mappe som webserveren stiller til rådighed, og den der kender adressen, kan læse den. Deri står stier, nogle gange brugernavne og anden information der kan hjælpe en indbrudstyv. Slå det fra igen efter du er færdig med at lede, og slet debug.log. Eller lad WordPress skrive logfilen uden for webmappen ved at angive en sti ved WP_DEBUG_LOG (for eksempel '/home/gebruiker/logs/wp-debug.log', hvis din hostingudbyder tillader det). I lektion 7.4 kontrollerer du at debug.log ikke er offentligt tilgængelig.

3. Slå en plugin fra uden kontrolpanel

Kan du ikke komme ind i kontrolpanelet, så slå den mistænkte plugin fra ved at omdøbe dens mappe, via Filhåndtering eller SFTP:

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress finder så ikke pluginnet mere og slår det fra. Ved du ikke hvilket plugin det er, så omdøb hele mappen plugins til plugins-uit: alle plugins bliver slået fra. Virker siden så, opret en ny tom mappe plugins, sæt pluginsene tilbage én for én og tjek efter hver plugin om fejlen kommer tilbage. For et tema gælder det samme: omdøb mappen for det aktive tema, og WordPress falder tilbage på et standardtema, hvis det stadig findes (lektion 2.4).

4. Konflikter uden fatal fejl

Ikke alle problemer er en kritisk fejl. Nogle gange virker én funktion bare ikke: en knap gør ingenting, formularen sender ikke, editoren indlæses kun delvist. Så er det ofte en konflikt mellem to plugins eller mellem en plugin og temaet. Her er det officielle plugin Health Check & Troubleshooting nyttigt: i fejlfindingstilstand slår det alle plugins fra kun for din session og skifter til et standardtema, mens besøgende stadig ser det normale websted. Derefter slår du dem til én for én, indtil problemet kommer tilbage.

Kig også i din browsers konsol (F12): JavaScript-fejl nævner ofte filen, og dermed pluginnet.

Webstedshelbred

Under Værktøjer > Webstedshelbred kontrollerer WordPress selv dit websted: forældet PHP-version, plugins og temaer der ikke er aktive, manglende PHP-udvidelser, en REST API der ikke virker, planlagte opgaver der halter bagud. Under fanen Info står alle oplysninger om din installation (versioner, stier, PHP-indstillinger). Den fane kan du kopiere og vedlægge, hvis du beder om hjælp. Kig her efter hver større ændring.

Opsummering

• Deaktivering lader filerne blive liggende; slet plugins og temaer du ikke bruger.
• Ryd op hvert kvartal, én plugin ad gangen, med en backup eller i et testmiljø.
• Ved en kritisk fejl sender WordPress en mail med et link til gendannelsestilstand.
• Fejlloggen eller debug.log nævner stien til synderen; slå debug fra igen efter du er færdig med at lede, for ellers er debug.log offentligt tilgængelig.
• Uden kontrolpanel slår du en plugin fra ved at omdøbe dens mappe; konflikter finder du med fejlfindingstilstanden.

Quiz

Opgave

Opgave A5.4: Er din debug-log ikke offentlig? Indtast adressen på dit websted og bevis med koden som opgaven giver dig, at det er dit eget websted (et TXT-record eller en lille fil). Programmet forsøger at hente /wp-content/debug.log: det er godt hvis den ikke findes eller afvises (404 eller 403). Får programmet en fil tilbage, er det rødt. Derudover tæller programmet hvor mange forskellige pluginmapper der findes i HTML'en på din forside (kun til orientering).

Opgave D5.4: Ryd op i din pluginliste. Lav en liste over alle dine plugins (aktive og inaktive): navn, hvad det bruges til, stadig nødvendigt (ja/nej), alternativ uden plugin. Slet (efter en backup eller i et testmiljø) de plugins der ikke længere er nødvendige, én ad gangen, og tjek efter hver sletning om siden stadig virker. Noter hvor mange plugins du havde, og hvor mange der er tilbage, og noter om der blev efterladt shortcodes som du måtte rydde op i.

Læs mere

Disse artikler beskriver trinnene i WebOkés kontrolpaneler; i andre kontrolpaneler fungerer det på lignende vis.

• DirectAdmin vejledning 18.1: Min hjemmeside er hvid eller giver en fejl 500
• Fejl 500 eller "kritisk fejl" på din hjemmeside (også efter en WordPress-opdatering)
• DirectAdmin vejledning 14.6: Fejl efter en PHP-opgradering og hvordan du finder fejlloggen
• DirectAdmin vejledning 17.2: Oversigt og logs for websted: fejlloggen og adgangsloggen
• Hvordan kan jeg debugge PHP uden at ændre php.ini?
• Debugging i WordPress (developer.wordpress.org, Engelsk): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/