Mindre är mer: städa upp och lösa konflikter

Modul 5: Teman och tillägg · Lästid: 9 minuter

Lärandemål: Efter den här lektionen kan du städa upp bland dina tillägg och själv hitta och lösa en konflikt eller en vit sida.

Nyckelbegrepp: inaktivera eller ta bort, inaktiv kod, kritiskt fel, återställningsläge (recovery mode), Hälsokontroll för webbplatser, felsökningsläge, byta namn på tilläggsmappen, WP_DEBUG, WP_DEBUG_LOG, debug.log, fellogg

Att stänga av är inte att slänga

Under Tillägg kan du inaktivera eller ta bort ett tillägg. Skillnaden:

• Inaktivera: WordPress laddar inte längre tillägget. Men filerna ligger kvar i wp-content/plugins/ och går ofta fortfarande att hämta direkt via webbservern. Finns det ett säkerhetshål i en enskild PHP-fil i tillägget, så finns hålet kvar. Inkräktare söker efter kända sårbara filer, inte efter aktiva tillägg.
• Ta bort: filerna försvinner. Vissa tillägg rensar också sina inställningar och tabeller i databasen när de tas bort, andra låter dem ligga kvar.

Använder du inte ett tillägg längre, ta bort det. Att inaktivera är bara för en kort stund (medan du letar efter ett problem). Samma sak gäller teman (lektion 2.4).

Städa upp: en fast genomgång

Gå igenom dina tillägg en gång per kvartal (lektion 9.4). För varje tillägg:

1. Vad är det till för? Vet du inte längre, ta reda på det. Ofta visar det sig att ett tillägg en gång installerades för en enda sak och aldrig togs bort.
2. Används det fortfarande? Ett slidertillägg fast det inte finns någon slider någonstans, ett formulärtillägg fast din kontaktsida använder ett annat formulär.
3. Klarar du dig utan? Kan WordPress, temat eller ett annat tillägg redan göra samma sak (lektion 5.3)?
4. Underhålls det fortfarande? När uppdaterades det senast, finns det kvar i tilläggskatalogen?

Städa först i en testmiljö (staging) (lektion 8.3), eller gör åtminstone en säkerhetskopia, och ta bort ett tillägg i taget så att du vet vad som gick fel om något går fel. Tänk på kortkoder (shortcodes): tar du bort ett tillägg som stod för [formular id="2"], så står den texten sedan bokstavligen på din sida.

När det går fel: det kritiska felet

Efter en uppdatering, ett nytt tillägg eller en PHP-uppgradering ser du plötsligt:

Det har uppstått ett kritiskt fel på denna webbplats.

eller en helt vit sida. Det betyder att PHP har stoppat med ett fatalt fel innan någon sida hann skapas (lektion 1.2). Oftast beror det på ett tillägg eller tema som inte fungerar ihop med något annat: ett annat tillägg, den nya versionen av WordPress eller PHP-versionen.

Sedan WordPress 5.2 gör WordPress då två saker:

• det skickar ett e-postmeddelande till administratörsadressen med vilket tillägg eller tema som orsakade felet, och en särskild länk;
• med den länken loggar du in i återställningsläget (recovery mode): administrationen fungerar då, med det felande tillägget tillfälligt avstängt, så att du kan uppdatera, byta ut eller ta bort det.

Därför är det så viktigt med en administratörsadress som du faktiskt läser (lektion 2.2).

Leta själv: stegen

Kommer det inget mejl, eller fungerar inte återställningsläget? Så här hittar du felet själv.

1. Titta i felloggen

Felet står nästan alltid i webbserverns eller PHP:s fellogg. I DirectAdmin hittar du den bland loggarna för din domän. Leta efter en rad med PHP Fatal error och tidpunkten för ditt försök:

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

Sökvägen visar vem som är boven: här tillägget i mappen gammal-slider. Resten av raden förklarar varför (här: en funktion som har tagits bort i PHP 8, lektion 8.4).

2. Slå på felsökningsloggen (inte visningen på skärmen)

Finns det inget användbart i felloggen, lägg då till följande i wp-config.php (ovanför raden ”stop editing”, i svenska versioner ”sluta redigera”):

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

WordPress skriver då alla fel till wp-content/debug.log, utan att visa dem för besökarna. Låt det aldrig vara påslaget längre än nödvändigt: debug.log ligger i en mapp som webbservern visar, och den som känner till adressen kan läsa filen. Där står sökvägar, ibland användarnamn och annan information som hjälper en inkräktare. Stäng av det igen när du har letat klart och ta bort debug.log. Eller låt WordPress skriva loggfilen utanför webbmappen genom att ange en sökväg vid WP_DEBUG_LOG (till exempel '/home/anvandare/logs/wp-debug.log', om ditt webbhotell tillåter det). I lektion 7.4 kontrollerar du att debug.log inte är offentlig.

3. Stänga av ett tillägg utan administrationen

Kommer du inte in i administrationen, stäng då av det misstänkta tillägget genom att byta namn på dess mapp, via Filhanterare eller SFTP:

wp-content/plugins/gammal-slider   blir   wp-content/plugins/gammal-slider-av

WordPress hittar då inte längre tillägget och stänger av det. Vet du inte vilket tillägg det är, byt då namn på hela mappen plugins till plugins-av: alla tillägg stängs av. Fungerar webbplatsen då, skapa en ny tom mapp plugins, flytta tillbaka tilläggen ett i taget och kontrollera efter varje tillägg om felet kommer tillbaka. Samma sak gäller ett tema: byt namn på mappen för det aktiva temat så faller WordPress tillbaka på ett standardtema, om det fortfarande finns kvar (lektion 2.4).

4. Konflikter utan fatalt fel

Alla problem är inte kritiska fel. Ibland fungerar bara en funktion inte: en knapp gör ingenting, formuläret skickas inte, redigeraren laddas bara till hälften. Då är det ofta en konflikt mellan två tillägg eller mellan ett tillägg och temat. Till det är det officiella tillägget Health Check & Troubleshooting praktiskt: i felsökningsläget stänger det av alla tillägg och byter till ett standardtema enbart för din session, medan besökarna ser den vanliga webbplatsen. Sedan slår du på dem ett i taget tills problemet kommer tillbaka.

Titta också i webbläsarens konsol (F12): JavaScript-fel nämner ofta filen och därmed tillägget.

Hälsokontroll för webbplatser

Under Verktyg > Hälsokontroll för webbplatser kontrollerar WordPress själv din webbplats: föråldrad PHP-version, tillägg och teman som inte är aktiva, saknade PHP-tillägg, ett REST API som inte fungerar, schemalagda uppgifter som ligger efter. På fliken Info finns alla uppgifter om din installation (versioner, sökvägar, PHP-inställningar). Den fliken kan du kopiera och skicka med när du ber om hjälp. Titta här efter varje större ändring.

Sammanfattning

• Att inaktivera låter filerna ligga kvar; ta bort tillägg och teman som du inte använder.
• Städa upp varje kvartal, ett tillägg i taget, med en säkerhetskopia eller i en testmiljö.
• Vid ett kritiskt fel skickar WordPress ett mejl med en länk till återställningsläget.
• Felloggen eller debug.log visar sökvägen till boven; stäng av felsökningen när du har letat klart, annars är debug.log offentlig.
• Utan administrationen stänger du av ett tillägg genom att byta namn på dess mapp; konflikter letar du upp med felsökningsläget.

Quiz

Uppgift

Uppgift A5.4: Är din felsökningslogg inte offentlig? Fyll i adressen till din webbplats och bevisa med koden som uppgiften ger dig att det är din egen webbplats (en TXT-post eller en liten fil). Programmet begär /wp-content/debug.log: det är bra om filen inte finns eller om åtkomst nekas (404 eller 403). Får programmet tillbaka en fil blir resultatet rött. Dessutom räknar programmet hur många olika tilläggsmappar som förekommer i HTML-koden på din startsida (endast som information).

Uppgift D5.4: Städa upp din tilläggslista. Gör en lista över alla dina tillägg (aktiva och inaktiva): namn, vad det är till för, behövs det fortfarande (ja/nej), alternativ utan tillägg. Ta bort (efter en säkerhetskopia eller i en testmiljö) de tillägg som inte längre behövs, ett i taget, och kontrollera efter varje borttagning att webbplatsen fortfarande fungerar. Fyll i hur många tillägg du hade och hur många som är kvar, och anteckna om det blev kvar kortkoder som du behövde städa bort.

Läs mer

De här artiklarna beskriver stegen i WebOkés paneler; i andra paneler fungerar det på liknande sätt.

• DirectAdmin-guide 18.1: Min webbplats är vit eller visar fel 500
• Fel 500 eller "kritiskt fel" på din webbplats (även efter en WordPress-uppdatering)
• DirectAdmin-guide 14.6: Fel efter en PHP-uppgradering och hitta fellogen
• DirectAdmin-guide 17.2: Webbplatssammanfattning och loggar: felloggen och åtkomstloggen
• Hur kan jag felsöka PHP utan att ändra php.ini?
• Felsökning i WordPress (developer.wordpress.org, engelska): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Välj, utvärdera och rensa WordPress-plugins