Feilretting på nettsted

Fikser årsaken, ikke symptomet

Et kontaktskjema slutter å sende. Den raske løsningen er å installere et annet skjemainnstikk, og skjemaet fungerer igjen en stund. Den egentlige årsaken er som regel at nettstedet sender e-post via webserveren i stedet for en ordentlig e-posttjeneste, og mottakende servere har begynt å avvise den. Bytt innstikket, og problemet kommer tilbake om en måned, nå med to skjemainnstikk installert.

Vi leter etter den underliggende årsaken først. Serverfeillogger, nettleserkonsollen og listen over nylige oppdateringer peker som regel rett på den. Mange feil på nettsteder viser seg å ha de samme få røttene: en oppdatering som endret hvordan en utvidelse oppfører seg, et cache-lag som viser en gammel versjon, et tema som ble redigert direkte og deretter overskrevet, eller en hostinggrense som er nådd.

Hvorfor vi fikser på en kopi først

Å endre et live nettsted for å finne en feil er hvordan et lite problem blir et avbrudd. En innstilling som slås av og på for å teste en teori, kan ødelegge kassen for alle besøkende mens testen kjører. Derfor lager vi en staging-kopi der leverandøren tillater det, reproduserer feilen der og beviser løsningen før vi rører live-nettstedet.

Hver jobb starter med en full sikkerhetskopi og avsluttes med en logg: hva som var galt, hva som forårsaket det, hva vi endret og hvor. Den loggen er nyttig lenge etter at vi er ferdige. Når samme symptom kommer tilbake etter en oppdatering, starter den neste som ser på det, fra svaret i stedet for fra scratch.

• Skjemaer som ikke sender: vanligvis e-postlevering, ikke skjemaet selv
• Oppsett ødelagt etter en oppdatering: vanligvis en endring i tema- eller bygger-versjon
• Endringer vises ikke: vanligvis caching på server-, plugin- eller CDN-nivå
• Hvit skjerm eller 500-feil: vanligvis en PHP-versjon eller minnegrense