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 tillägg och själv upptäcka och lösa en konflikt eller en vit sida.

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

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

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 är ofta fortfarande direkt hämtbara via webbservern. Finns det en säkerhetslucka i en enskild PHP-fil i det tillägget, finns den luckan fortfarande kvar. Inbrottsförsök sker genom att man letar efter kända sårbara filer, inte efter aktiva tillägg.
• Ta bort: filerna försvinner. Vissa tillägg städar även upp sina inställningar och tabeller i databasen när de tas bort; andra lämnar dem kvar.

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

Städa upp: en fast rutin

Gå igenom dina tillägg en gång i kvartalet (lektion 9.4). Per 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 sedan aldrig togs bort.
2. Används det fortfarande? Ett tillägg för bildspel fast det inte finns något bildspel någonstans, ett formulärtillägg fast din kontaktsida använder ett annat formulär.
3. Går det utan? Kan WordPress, temat eller ett annat tillägg redan göra det (lektion 5.3)?
4. Underhålls det fortfarande? Senast uppdaterad, finns det fortfarande kvar i pluginkatalogen?

Gör städningen först i en testmiljö (staging) (lektion 8.3), eller ta å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å shortcodes: tar du bort ett tillägg som levererade [formulier id="2"], står den texten bokstavligt kvar på din sida efteråt.

Om något 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å webbplatsen.

eller en helt vit sida. Det betyder att PHP har stoppats av ett fatalt fel innan en sida hann byggas (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 mejl 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 tillägget som orsakade felet tillfälligt avstängt, så att du kan uppdatera, ersätta eller ta bort det.

Därför är en administratörsadress som du läser så viktig (lektion 2.2).

Leta själv: stegen

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

1. Titta i felloggen

Felet står nästan alltid i felloggen för webbservern eller för PHP. I DirectAdmin hittar du det bland loggarna för din domän. Du letar 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/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

Sökvägen berättar vem den skyldige är: här tillägget i mappen oude-slider. Resten av raden berättar varför (här: en funktion som har tagits bort i PHP 8, lektion 8.4).

2. Sätt på felloggen debug (inte skärmvisningen)

Står det inget användbart i felloggen, lägg då till i wp-config.php (ovanför "det räcker, 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ökare. Låt aldrig detta vara påslaget längre än nödvändigt: debug.log ligger i en mapp som webbservern erbjuder, och den som känner till adressen kan läsa den. Där står sökvägar, ibland användarnamn och annan information som hjälper en inkräktare. Stäng av det igen efter sökningen och ta bort debug.log. Eller låt WordPress skriva loggfilen utanför webbkatalogen genom att ange en sökväg vid WP_DEBUG_LOG (till exempel '/home/gebruiker/logs/wp-debug.log', om ditt webbhotell tillåter det). I lektion 7.4 kontrollerar du att debug.log inte är offentlig.

3. Stäng av ett tillägg utan administration

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/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress hittar då inte längre tillägget och stänger av det. Vet du inte vilket det är, byt namn på hela mappen plugins till plugins-uit: alla tillägg stängs av. Fungerar webbplatsen då, skapa en ny tom mapp plugins, lägg tillbaka tilläggen ett i taget och kontrollera efter varje tillägg om felet återkommer. För ett tema gäller samma sak: 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

Inte alla problem är ett kritiskt fel. Ibland fungerar bara en funktion inte: en knapp gör ingenting, formuläret skickas inte, redigeraren laddar halvvägs. Då är det ofta en konflikt mellan två tillägg eller mellan ett tillägg och temat. Då är det officiella tillägget Health Check & Troubleshooting praktiskt: i felsökningsläget stänger det av alla tillägg och växlar till ett standardtema, men bara för din egen session, medan besökare fortfarande ser den vanliga webbplatsen. Sedan sätter du på dem ett i taget tills problemet återkommer.

Titta även i konsolen i din webbläsare (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 (extensions), 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 stor ändring.

Sammanfattning

• Inaktivera lämnar filerna 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 anger sökvägen till den skyldige; stäng av debug igen efter sökningen, för annars är debug.log offentlig.
• Utan administration stänger du av ett tillägg genom att byta namn på dess mapp; konflikter söker du 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 hämtar /wp-content/debug.log: det är bra om den inte finns eller nekas (404 eller 403). Får programmet tillbaka en fil är det rött. Dessutom räknar programmet hur många olika pluginmappar 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, fortfarande nödvändigt (ja/nej), alternativ utan tillägg. Ta bort (efter en säkerhetskopia eller i en testmiljö) tilläggen som inte längre behövs, ett i taget, och kontrollera efter varje borttagning om webbplatsen fortfarande fungerar. Fyll i hur många tillägg du hade och hur många som är kvar, och notera om det blev kvar några shortcodes som du var tvungen att städa upp.

Läs mer

De här artiklarna beskriver stegen i WebOkés paneler; i andra paneler fungerar det på ett 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/