Mindre er mer: rydd opp og løs konflikter

Modul 5: Temaer og utvidelser · Lesetid: 9 minutter

Læringsmål: Etter denne leksjonen kan du rydde opp i utvidelser og selv finne og løse en konflikt eller en hvit side.

Nøkkelbegreper: deaktivere vs slette, inaktiv kode, kritisk feil, gjenopprettingsmodus (recovery mode), Nettstedshelse, feilsøkingsmodus, gi pluginmappen nytt navn, WP_DEBUG, WP_DEBUG_LOG, debug.log, feillogg

Å slå av er ikke det samme som å kaste ut

Under Utvidelser kan du deaktivere eller slette en utvidelse. Forskjellen:

• Deaktivere: WordPress laster ikke lenger inn utvidelsen. Men filene blir liggende i wp-content/plugins/, og er ofte fortsatt tilgjengelige direkte via webserveren. Er det en sårbarhet i en løs PHP-fil i utvidelsen, er den fortsatt der. Inntrengere skanner etter kjente sårbare filer, ikke etter aktive utvidelser.
• Slette: filene forsvinner. Noen utvidelser rydder også opp innstillinger og tabeller i databasen når de slettes; andre lar dem stå.

Bruker du ikke en utvidelse lenger, slett den. Deaktivering er bare for en kort stund (mens du leter etter et problem). Det samme gjelder for temaer (leksjon 2.4).

Opprydding: en fast runde

Gå gjennom utvidelsene dine én gang i kvartalet (leksjon 9.4). For hver utvidelse:

1. Hva er den til? Vet du det ikke lenger, finn det ut. Ofte viser det seg at en utvidelse en gang ble installert for én ting og aldri fjernet.
2. Brukes den fortsatt? En slider-utvidelse mens ingen steder viser en slider, en skjemautvidelse mens kontaktsiden din bruker et annet skjema.
3. Går det uten? Kan WordPress, temaet eller en annen utvidelse allerede gjøre det (leksjon 5.3)?
4. Vedlikeholdes den fortsatt? Sist oppdatert, fortsatt i utvidelseskatalogen?

Gjør oppryddingen først i et testmiljø (staging) (leksjon 8.3), eller ta minst en sikkerhetskopi, og slett én utvidelse av gangen slik at du vet hva som gikk galt hvis noe går galt. Pass på shortcodes: sletter du en utvidelse som leverte [formulier id="2"], blir den teksten liggende bokstavelig på siden din etterpå.

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

Etter en oppdatering, en ny utvidelse eller en PHP-oppgradering ser du plutselig:

En kritisk feil har inntruffet på dette nettstedet.

eller en helt hvit side. Det betyr: PHP har stoppet med en fatal feil før det var noen side (leksjon 1.2). Som regel skyldes det en utvidelse eller et tema som ikke går overens med noe annet: en annen utvidelse, den nye versjonen av WordPress, eller PHP-versjonen.

Siden WordPress 5.2 gjør WordPress da to ting:

• det sender en e-post til administratoradressen med hvilken utvidelse eller hvilket tema som ga feilen, og en spesiell lenke;
• med den lenken logger du inn i gjenopprettingsmodus (recovery mode): kontrollpanelet fungerer da, med utvidelsen som ga feilen midlertidig slått av, slik at du kan oppdatere, erstatte eller slette den.

Derfor er en administratoradresse du faktisk leser, så viktig (leksjon 2.2).

Finn det selv: stegene

Kommer det ingen e-post, eller fungerer ikke gjenopprettingsmodus? Slik finner du det selv.

1. Se i feilloggen

Feilen står nesten alltid i feilloggen til webserveren eller PHP. I DirectAdmin finner du den under loggene for domenet ditt. Du leter etter en linje med PHP Fatal error og tidspunktet for forsøket ditt:

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 forteller deg hvem synderen er: her utvidelsen i mappen oude-slider. Resten av linjen forteller hvorfor (her: en funksjon som er fjernet i PHP 8, leksjon 8.4).

2. Slå på feilloggen (ikke skjermvisningen)

Står det ingenting nyttig i feilloggen, sett da i wp-config.php (over «det er nok, slutt å redigere herfra!»):

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

WordPress skriver da alle feil til wp-content/debug.log, uten å vise dem til besøkende. La aldri dette stå på lenger enn nødvendig: debug.log ligger i en mappe webserveren tilbyr, og den som kjenner adressen, kan lese den. Der står det stier, noen ganger brukernavn og annen informasjon som hjelper en inntrenger. Slå det av igjen etter at du er ferdig å søke, og slett debug.log. Eller la WordPress skrive loggfilen utenfor webmappen ved å angi en sti ved WP_DEBUG_LOG (for eksempel '/home/gebruiker/logs/wp-debug.log', hvis webhotellet ditt tillater det). I leksjon 7.4 kontrollerer du at debug.log ikke er offentlig.

3. Slå av en utvidelse uten kontrollpanel

Kommer du ikke inn i kontrollpanelet, slå da av den mistenkte utvidelsen ved å gi mappen nytt navn, via File Manager eller SFTP:

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

WordPress finner da ikke utvidelsen lenger og slår den av. Vet du ikke hvilken det er, gi da hele mappen plugins nytt navn til plugins-uit: alle utvidelser slås av. Fungerer nettstedet da, lag en ny tom mappe plugins, sett utvidelsene tilbake én etter én og sjekk etter hver utvidelse om feilen kommer tilbake. For et tema gjelder det samme: gi mappen til det aktive temaet nytt navn, så faller WordPress tilbake på et standardtema, hvis det fortsatt ligger der (leksjon 2.4).

4. Konflikter uten fatal feil

Ikke alle problemer er en kritisk feil. Noen ganger fungerer bare én funksjon ikke: en knapp gjør ingenting, skjemaet sender ikke, redigeringsverktøyet laster bare delvis. Da er det ofte en konflikt mellom to utvidelser eller mellom en utvidelse og temaet. Til det er den offisielle utvidelsen Health Check & Troubleshooting nyttig: i feilsøkingsmodus slår den av alle utvidelser kun for din egen økt og bytter til et standardtema, mens besøkende fortsatt ser det vanlige nettstedet. Deretter slår du dem på én etter én til problemet kommer tilbake.

Se også i konsollen i nettleseren din (F12): JavaScript-feil nevner ofte filen, og dermed utvidelsen.

Nettstedshelse

Under Verktøy > Nettstedshelse kontrollerer WordPress selv nettstedet ditt: utdatert PHP-versjon, utvidelser og temaer som ikke er aktive, manglende PHP-utvidelser, et REST API som ikke fungerer, planlagte oppgaver som henger etter. Under fanen Info står alle opplysninger om installasjonen din (versjoner, stier, PHP-innstillinger). Den fanen kan du kopiere og sende med hvis du ber om hjelp. Sjekk her etter hver større endring.

Oppsummering

• Deaktivering lar filene ligge; slett utvidelser og temaer du ikke bruker.
• Rydd opp hvert kvartal, én utvidelse av gangen, med en sikkerhetskopi eller i testmiljø.
• Ved en kritisk feil sender WordPress en e-post med en lenke til gjenopprettingsmodus.
• Feilloggen eller debug.log oppgir stien til synderen; slå av debug igjen etter at du er ferdig å søke, for ellers er debug.log offentlig.
• Uten kontrollpanel slår du av en utvidelse ved å gi mappen nytt navn; konflikter finner du med feilsøkingsmodus.

Quiz

Oppgave

Oppgave A5.4: Er debug-loggen din ikke offentlig? Fyll inn adressen til nettstedet ditt og bevis med koden oppgaven gir deg at det er ditt eget nettsted (en TXT-post eller en liten fil). Programmet henter /wp-content/debug.log: det er bra hvis den ikke finnes eller avvises (404 eller 403). Får programmet en fil tilbake, blir det rødt. I tillegg teller programmet hvor mange forskjellige utvidelsesmapper som forekommer i HTML-en på forsiden din (kun til informasjon).

Oppgave D5.4: Rydd opp i utvidelseslisten din. Lag en liste over alle utvidelsene dine (aktive og inaktive): navn, hva den er til, fortsatt nødvendig (ja/nei), alternativ uten utvidelse. Slett (etter en sikkerhetskopi eller i testmiljø) utvidelsene som ikke lenger trengs, én av gangen, og sjekk etter hver sletting om nettstedet fortsatt fungerer. Fyll inn hvor mange utvidelser du hadde og hvor mange som er igjen, og noter om det ble liggende igjen shortcodes du måtte rydde opp i.

Les mer

Disse artiklene beskriver stegene i kontrollpanelene til WebOké; i andre kontrollpaneler fungerer de på lignende måte.

• DirectAdmin-veiledning 18.1: Nettstedet mitt er hvitt eller gir feil 500
• Feil 500 eller «kritisk feil» på nettstedet ditt (også etter en WordPress-oppdatering)
• DirectAdmin-veiledning 14.6: Feil etter en PHP-oppgradering og finne feilloggen
• DirectAdmin-veiledning 17.2: Site summary & logs: feillogg og tilgangslogg
• Hvordan kan jeg feilsøke PHP uten å endre php.ini?
• Feilsøking i WordPress (developer.wordpress.org, engelsk): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/