WordPress-hjelp: hva du gjør før du melder feil

#Før du skriver: ti minutter triage

Fire spørsmål, i denne rekkefølgen. Svarene peker som regel på årsaken raskere enn noe verktøy.

Hva virker egentlig ikke. Hele nettstedet, én underside, eller bare administrasjonspanelet? Åpne adressen i et privat vindu og på en annen forbindelse, for eksempel på mobil over mobildata. Virker siden i privat vindu, ligger problemet i nettleserens cache eller i økten din, ikke på serveren. Virker den på mobilen, men ikke på kontoret, sjekk DNS og brannmur hos deg selv før noen begynner å grave i WordPress.

Hva er den nøyaktige meldingen. «Virker ikke» er fem forskjellige feil. Hvit skjerm er som regel en PHP-feil med feilvisning slått av. 500-feil er en serverfeil, oftest en utvidelse, et tema eller en minnegrense. «Error establishing a database connection» handler om databasen, altså et helt annet spor. 403 ved innlogging er som regel en sikkerhetsregel, ikke en feil. Noter koden og hele teksten, inkludert linjenummer hvis det står der.

Hva ble endret rett før. Feil oppstår sjelden av seg selv. Oppdatering av en utvidelse, oppdatering av kjernen, endret PHP-versjon hos webhotellet, utløpt sertifikat, endret DNS-oppføring, utløpt domene, overskredet grense hos webhotellet. Dato og klokkeslett for siste endring er som regel den mest verdifulle opplysningen i hele meldingen.

Har du en sikkerhetskopi. Ikke gjenopprett den på refleks, men slå fast at den finnes og når den er fra. Tar webhotellet nattlige kopier, se i panelet når den siste ble tatt. Det er den opplysningen som avgjør om en reparasjon er risikabel eller reversibel.

#Feilmelding, lag, første handling

Denne tabellen korter ned det lengste trinnet i enhver driftsstans, nemlig gjettingen om hvor man i det hele tatt skal lete.

Midtkolonnen er viktigere enn den høyre. Mesteparten av tiden som går tapt i en driftsstans, går med til å reparere feil lag: noen slår av utvidelser når problemet ligger i DNS, eller flytter webhotell når skylden ligger hos én utvidelse som spør et eksternt API.

#Hvor loggene ligger og hva du leter etter i dem

Uten logg er diagnosen gjetting. Det finnes tre steder, i denne rekkefølgen etter nytte.

PHP-feilloggen. På de fleste delte webhotell ligger den som error_log i katalogen til nettstedet, eller i panelet under loggseksjonen. Du leter etter de siste oppføringene med PHP Fatal error fra tidspunktet feilen oppsto. En slik oppføring inneholder fil og linjenummer, og det peker som regel ut den skyldige utvidelsen i løpet av det første sekundet.

WordPress-loggen. Gir webhotellet deg ingen PHP-logg, slå på din egen. I wp-config.php, over linjen med kommentaren «That’s all, stop editing»:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Feilene havner i wp-content/debug.log, og de besøkende ser ingenting. Etter diagnosen slår du det av og sletter filen; en logg som blir liggende en måned i produksjon kan vokse til gigabyte og selv bli en driftsstans.

Webserverloggen. Nginx og Apache skriver tilgang og feil hver for seg. Det er den andre du er ute etter, fra klokkeslettet hendelsen skjedde. På et webhotell med skalltilgang holder det med tail -n 100 /sti/til/logs/error.log. Har du bare et panel, last ned filen og åpne den i et tekstredigeringsprogram, ikke i et regneark, for da blir lange linjer kappet.

Hva du ser etter i alle tre: et tidsstempel som stemmer med tidspunktet for feilen, den samme linjen som gjentar seg (det er som regel en løkke, ikke en tilfeldighet) og navnet på en utvidelseskatalog i filstien. Hva du ikke skal gjøre: ikke lim inn en fil på ti tusen linjer i meldingen. Tjue linjer rundt første forekomst av feilen er mer verdt enn hele filen.

#Fire vanligste feil og førstehjelpen

Stegene nedenfor er trygge, reversible og krever ingen utvikler. Går et av dem utover det du er komfortabel med, stopp og skriv til oss; en avbrutt reparasjon er lettere å fullføre enn en som har gravd seg dypere.

Hvit skjerm eller 500-feil etter en oppdatering. Slå først av utvidelsen som sist ble oppdatert. Har du ikke tilgang til panelet, gi katalogen dens et nytt navn i wp-content/plugins/ via filbehandleren hos webhotellet eller FTP; da deaktiverer WordPress den. Hjelper ikke det, gi hele plugins-katalogen navnet plugins-off, sjekk siden og sett navnet tilbake. Det avgjør på et minutt om skylden ligger hos en utvidelse eller hos temaet. Har du tilgang til kommandolinjen, gjør wp plugin deactivate --all det samme på en ryddigere måte og lar deg slå på utvidelsene én etter én.

Nettstedet ble plutselig tregt. Sjekk om det er visningen av siden eller panelet som er tregt. Tregt panel med rask forside er som regel databasen eller et eksternt API, for eksempel en utvidelse som spør en lisensserver ved hvert besøk. Treg forside med raskt panel er som regel cache, bilder eller webhotellet. Mål før du optimaliserer: PageSpeed Insights viser både laboratorieresultatet og data fra virkelige brukere via CrUX, og de siste veier tyngst, fordi de beskriver det folk faktisk opplever og ikke en simulering. Sjekk serverens svartid for seg, for eksempel med curl -o /dev/null -s -w "%{time_starttransfer}\n" https://dittdomene.no/. Et resultat over ett sekund betyr et problem på serversiden, ikke i bilder eller skript.

Jeg får ikke logget inn. Før du kaller det en driftsstans, sjekk tre ting: om innloggingsadressen er endret av en sikkerhetsutvidelse, om IP-adressen din er blokkert etter mislykkede forsøk, og om klokken på serveren har gått i utakt, for det ødelegger økter. Tilbakestilling av passord via skjemaet krever at e-post virker, så går det ingen e-post ut, virker heller ikke det. Nødutgangen: wp user update admin --user_pass=NyttPassord fra kommandolinjen, eller endring av passordet direkte i databasen med MD5-funksjonen, som WordPress godtar ved første innlogging og straks bytter ut med sin egen hash.

Mistanke om infeksjon. Symptomer: omdirigering til et fremmed domene bare fra søkeresultater, nye administratorer du ikke har opprettet, en advarsel i Search Console, spam i innholdet som bare Googlebot ser. Sjekk listen over brukere med administratorrolle og endringsdatoene på filene, for eksempel med find . -type f -mtime -7 -name "*.php", for å se hva som er endret den siste uken. Ikke slett filer og ikke gjenopprett en kopi før du vet når det første innbruddet skjedde; en kopi fra en uke tilbake inneholder som regel samme hull. Bytt passord, også til databasen og FTP, og skriv til oss med merknad om infeksjon.

#En feil i en WooCommerce-butikk har en annen rekkefølge

I en nettbutikk er refleksen «slå av alle utvidelser» dyr, fordi den sammen med diagnosen slår av betaling, frakt og lagerintegrasjoner. Rekkefølgen er motsatt av på et vanlig presentasjonsnettsted.

Slå først fast om bestillinger kommer inn. Ordrelisten fra den siste timen svarer på det raskere enn noen logg. Kommer de inn samtidig som kundene melder om problemer, ligger feilen i varslene eller i betalingen, ikke i selve butikken. Kommer de ikke inn i det hele tatt, sjekk handlekurven og kassen i et privat vindu, for begge er unntatt fra cache og feiler annerledes enn resten av nettstedet.

E-postvarsler er en egen og svært vanlig feil som ser ut som en butikkfeil. Sjekk om e-post går ut i det hele tatt, og om den havner i mottakerens søppelpost. Tre DNS-oppføringer avgjør dette nesten helt: SPF, DKIM og DMARC. Sender butikken e-post direkte fra webhotellets server uten disse oppføringene, kommer en del av meldingene ikke fram, og ingen endring i en utvidelse reparerer det.

Gjelder feilen bare én betalingsmetode, sjekk i panelet hos leverandøren om en API-nøkkel eller et integrasjonssertifikat har gått ut. Dette er situasjonen der nettstedet virker som det skal, loggene er rene og salget står stille, så uten en sjekk hos leverandøren kan man lete i timevis i sin egen kode.

#Når det ikke er nettstedet som er nede i det hele tatt

Fire tilfeller der WordPress er uskyldig, og diagnostikk på den siden bare koster tid.

Domenet har gått ut. Symptom: i stedet for nettstedet ser du registrarens tilbud eller ingenting. Det sjekker du i whois-databasen, med ett oppslag, og du ser utløpsdatoen. Fornyelse virker som regel i løpet av et kvarters tid, men i ekstreme tilfeller går domenet inn i en innløsningsperiode og koster mange ganger mer enn en vanlig forlengelse.

DNS-endringen har ikke spredd seg ennå. Symptom: noen ser det nye nettstedet, andre det gamle. dig dittdomene.no +short viser hvilken adresse domenet peker til sett fra din side. Endringer sprer seg etter TTL-verdien, så har noen satt den til et døgn, tar det akkurat så lang tid, og det kan ikke framskyndes fra nettstedets side.

Sertifikatet har gått ut. Symptom: en advarsel i nettleseren om en tilkobling som ikke er sikker. Utløpsdatoen leser du av med openssl s_client -connect dittdomene.no:443 2>/dev/null | openssl x509 -noout -dates. Automatisk fornyelse kan feile når DNS er endret i mellomtiden, eller når det er lagt inn en omdirigering som blokkerer verifiseringen.

Webhotellet har suspendert kontoen. Symptom: en melding fra webhotellet i stedet for nettstedet, noen ganger etter en overskredet trafikkgrense eller en ubetalt faktura. Her er det ingenting å reparere i koden, det er bare en samtale med webhotellet, men det er verdt å finne ut etterpå hva som genererte trafikken, for like ofte er det en bot og ikke kunder.

#Hva du sender inn

Jo mer av denne listen du oppgir med én gang, jo færre runder med spørsmål, og jo raskere får du et faglig svar i stedet for en bønn om flere opplysninger.

Hva du ikke skal sende i første melding: passord. Tilgang avtaler vi etter omfanget, og helst som en egen administratorkonto du sletter når arbeidet er ferdig. Haster det, skriv det rett ut og si hva som ligger i at det haster: at nettbutikken ikke tar imot bestillinger er noe annet enn at kontaktskjemaet sender to ganger.

#Hva som skjer hos oss

Meldingen går til én person, ikke til en førstelinjekø, så du forklarer ikke saken to ganger. Første svar inneholder det vi har klart å slå fast ut fra beskrivelsen din, og spørsmål bare om det som faktisk mangler.

Så kommer diagnosen. Den er et eget, avgrenset trinn med sin egen pris, så du vet hva du sier ja til før noen rører nettstedet. Resultatet er årsaken, omfanget av reparasjonen og kostnaden, skriftlig. Arbeidet starter når omfanget er bekreftet, ikke etter et muntlig «bare kjør på». Dukker det underveis opp noe utenfor omfanget, stopper vi og priser det for seg, i stedet for å legge det på regningen i ettertid.

Reparasjonen gjør vi på en kopi eller i et testmiljø overalt der det lar seg gjøre, og endringer i produksjon går inn som én utrulling som kan rulles tilbake. Når arbeidet er ferdig, får du en beskrivelse av hva årsaken var og hva som skal til for at det ikke kommer tilbake. Det siste er som regel viktigere enn selve reparasjonen, for en feil som kommer tilbake om tre måneder koster en gang til.

#Hva vi ikke gjør

Vi lager ikke grafisk design. Layout og plassering av elementer i visningen, altså wireframe, leveres av kunden; vi bygger et responsivt grensesnitt, integrasjoner og ytelseslaget ut fra den. Til å samle inn oppsettet har vi en ferdig regnearkmal som vi sender ved oppstart.

Vi har verken natt- eller helgevakt, og vi selger ingen responstid vi ikke kan holde. Krever nettbutikken din et garantert responsvindu, er det en egen avtale om løpende drift, ikke et tillegg til en feilmelding.

Vi gjør ingenting «på siden av». Alt nytt som dukker opp underveis får sitt eget pristilbud. Det høres stivt ut, men i praksis sparer det begge parter for en regning ingen ventet.

Vi selger heller ingen ombygging som svar på en driftsstans. Lar nettstedet seg reparere på noen timer, sier vi det, selv om et forslag om migrering ville vært mer lønnsomt for oss. Migrering gir mening når kostnaden ved å drifte den nåværende løsningen overstiger kostnaden ved å bytte, og det lar seg regne ut, ikke bare ane.

#Når nettstedet kom tilbake av seg selv, er saken ikke lukket

En feil som gikk over uten inngrep er verre enn en som varer, for den forsvinner sammen med sporene og kommer tilbake på et dårligere tidspunkt. De tre vanligste årsakene til feil som kommer og går ser like ut fra utsiden.

Den første er en ressursgrense. Et delt webhotell tildeler nettstedet et bestemt antall samtidige PHP-prosesser, og avviser videre forespørsler når det tallet overskrides, som regel med 503 eller 508. Det holder at en bot går gjennom butikken med filtre, og i tre minutter svarer nettstedet ingen. I tilgangsloggen ser du da en serie forespørsler fra én adresse i samme sekund.

Den andre er en planlagt oppgave. WordPress kjører sin egen planlegger i forbindelse med besøk, så en tung oppgave, for eksempel generering av en rapport eller synkronisering med lageret, treffer en tilfeldig bruker og blokkerer siden for vedkommende. Symptom: feil på regelmessige tidspunkter eller alltid etter den samme handlingen i panelet.

Den tredje er et eksternt API uten tidsgrense. En utvidelse spør leverandørens server, leverandøren har driftsstans, og nettstedet ditt venter på svar så lenge PHP-konfigurasjonen tillater. Da er ikke nettstedet ødelagt, det venter bare, og det kommer tilbake av seg selv når den serveren er oppe igjen.

Slik fanger du det neste gang: slå på skriving av feil til fil før det kommer tilbake, noter de nøyaktige klokkeslettene for hendelsene de siste dagene, og se om de danner et mønster. Tre tidsstempler og en logg er et sett det går an å jobbe med. Uten dem gjenstår bare å vente på neste gang.

#Hvor du går videre

Vet du allerede hva du trenger, gå rett til riktig side i stedet for å skrive en generell henvendelse.

• Feil, driftsstans, noe sluttet å virke: reparasjon, service og teknisk støtte
• Løpende drift, oppdateringer, kopier og overvåking: vedlikehold av WordPress-nettsteder
• Mistanke om innbrudd eller revisjon før lansering: sikkerhetsrevisjon av WordPress
• Nettstedet virker, men er tregt: gjør WordPress-nettstedet raskere
• Nytt prosjekt eller ombygging: kontaktsiden

#To ting å gjøre i dag, før noe ryker

Sjekk om sikkerhetskopien din faktisk lar seg gjenopprette. Ikke om den finnes, men om den virker. En sikkerhetskopi ingen noen gang har gjenopprettet er en antakelse, ikke en sikring, og øyeblikket noe ryker er det verste tidspunktet å finne det ut på. Prosedyren tar en halvtime: sett opp et testmiljø hos det samme webhotellet, gjenopprett den siste kopien der, logg inn i panelet, åpne tre tilfeldige undersider og sjekk om antallet innlegg og bestillinger stemmer med produksjon. Skriv ned hvor lang tid det tok, for det er den reelle tiden det tar deg å komme tilbake etter en driftsstans, og den er bedre å kjenne fra en øvelse enn fra en krise.

Den andre tingen tar ett minutt: skriv ned hvor domenet ligger, hvor webhotellet ligger, hvem som har tilgang til dem og når de utløper. Overraskende ofte er feilen ingen feil, men et utløpt domene eller sertifikat, og svaret på «hvor ligger dette» tar en halv dag fordi den som satte det opp sluttet i firmaet for lenge siden. På det samme arket skriver du opp hvem som er administrator i WordPress, og om hver av de kontoene fortsatt trengs. Kontoer som tilhørte tidligere medarbeidere er den vanligste inngangen ingen holder øye med.