Mindre er mere: ryd op og løs konflikter

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

Læringsmål: Efter denne lektion kan du rydde op i dine plugins og selv finde 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 pluginmappen, WP_DEBUG, WP_DEBUG_LOG, debug.log, fejllog

At slå fra er ikke at smide ud

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

• Deaktiver: WordPress indlæser ikke længere pluginet. Men filerne bliver liggende i wp-content/plugins/, og de kan ofte stadig hentes direkte via webserveren. Er der et sikkerhedshul i en enkelt PHP-fil i pluginet, så er hullet der stadig. Angribere scanner efter kendte sårbare filer, ikke efter aktive plugins.
• Slet: filerne forsvinder. Nogle plugins rydder også deres indstillinger og tabeller i databasen op, når du sletter dem; andre lader dem blive.

Bruger du ikke længere et plugin, så slet det. Deaktivering er kun til kortvarig 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 hvert plugin:

1. Hvad bruges det til? Kan du ikke huske det, så find ud af det. Ofte viser det sig, at et plugin engang blev installeret til én ting og aldrig fjernet igen.
2. Bliver det stadig brugt? Et sliderplugin, selv om der ikke er en slider nogen steder, eller et formularplugin, selv om din kontaktside bruger en anden formular.
3. Kan du undvære det? Kan WordPress, temaet eller et andet plugin allerede gøre det samme (lektion 5.3)?
4. Bliver det stadig vedligeholdt? Hvornår blev det sidst opdateret, og findes det stadig i pluginmappen?

Ryd først op i testmiljøet (staging) (lektion 8.3), eller tag i det mindste en backup, og slet ét plugin ad gangen, så du ved, hvad der gik galt, hvis noget går galt. Hold øje med shortcodes: sletter du et plugin, der leverede [formulier id="2"], så står den tekst bagefter helt bogstaveligt på din side.

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

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

Der er opstået en kritisk fejl på dette websted.

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

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

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

Derfor er det så vigtigt at have en administratoradresse, som du faktisk læser (lektion 2.2).

Find det selv: trinene

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

1. Kig i fejlloggen

Fejlen står næsten altid i fejlloggen fra webserveren eller PHP. 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 der er synderen: her pluginet i mappen oude-slider. Resten af linjen fortæller hvorfor (her: en funktion, der er fjernet i PHP 8, lektion 8.4).

2. Slå debugloggen til (ikke visning på skærmen)

Står der ikke noget brugbart i fejlloggen, så tilføj dette 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 det aldrig være slået til længere end nødvendigt: debug.log ligger i en mappe, som webserveren udleverer, og alle, der kender adressen, kan læse den. Den indeholder stier, nogle gange brugernavne og andre oplysninger, der hjælper en angriber. Slå det fra igen, når 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 offentlig.

3. Slå et plugin fra uden administrationen

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

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

WordPress kan så ikke længere finde pluginet og slår det fra. Ved du ikke, hvilket plugin det er, så omdøb hele mappen plugins til plugins-uit: alle plugins slås fra. Virker webstedet så, opretter du en ny tom mappe plugins, flytter plugins tilbage ét ad gangen og tjekker efter hvert plugin, om fejlen kommer igen. Det samme gælder for et tema: omdøb mappen med det aktive tema, så falder WordPress tilbage på et standardtema, hvis der stadig er et (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 sendes ikke, editoren indlæses kun halvt. Så er det ofte en konflikt mellem to plugins eller mellem et plugin og temaet. Her er det officielle plugin Health Check & Troubleshooting nyttigt: i fejlfindingstilstand slår det alle plugins fra og skifter til et standardtema, men kun for din egen session, mens besøgende ser det normale websted. Derefter slår du dem til ét ad gangen, indtil problemet kommer igen.

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

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, et REST API, der ikke virker, planlagte opgaver, der halter bagud. På fanen Info står alle oplysninger om din installation (versioner, stier, PHP-indstillinger). Den fane kan du kopiere og sende med, når 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, ét plugin ad gangen, med en backup eller i testmiljøet.
• Ved en kritisk fejl sender WordPress en mail med et link til gendannelsestilstanden.
• Fejlloggen eller debug.log nævner stien til synderen; slå debug fra igen efter fejlsøgningen, for ellers er debug.log offentlig.
• Uden administrationen slår du et plugin fra ved at omdøbe dets 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 den kode, som opgaven giver dig, at det er dit eget websted (en TXT-record eller en lille fil). Programmet henter /wp-content/debug.log: det er godt, hvis den ikke findes eller bliver afvist (404 eller 403). Får programmet en fil tilbage, er resultatet rødt. Derudover tæller programmet, hvor mange forskellige pluginmapper der forekommer i HTML-koden 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 testmiljøet) de plugins, der ikke længere er nødvendige, ét ad gangen, og tjek efter hver sletning, om webstedet stadig virker. Udfyld, hvor mange plugins du havde, og hvor mange der er tilbage, og notér, om der var shortcodes tilbage, som du skulle rydde op i.

Læs mere

Disse artikler beskriver trinene i WebOkés paneler; i andre paneler fungerer de på lignende måde.

• 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?
• Fejlsøgning i WordPress (developer.wordpress.org, engelsk): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Vælg, vurder og ryd op i WordPress-plugins