En dag fikk jeg en e-post fra en lokal bedrift. Bedriftseieren kunne fortelle at nettsiden deres hadde krasjet. Eller som kunden selv sa «hadde gått i lås». Alt de så var en hvit skjerm. Han spurte meg rett ut: «Kan du redde nettsiden?»
Jeg var ganske sikker på at dette lot seg løse. Etter over 20 år med PHP har jeg sett det meste. Bedriften lurte også på om jeg kunne oppdatere siden og få den til å fungere igjen og hvor lang tid det ville ta.
Jeg forklarte kunden at det er litt som når en bil ikke starter. Før mekanikeren har funnet feilen, er det umulig å vite om reparasjonen tar ti minutter eller en hel dag.
Table of contents
Hypoteser
Før jeg hadde tilgang til nettstedet hadde jeg fire arbeidshypoteser
- Kan problemet være en utdatert PHP-versjon
- Kan det være databasen?
- Kan det være WordPress?
- Kan det være en plugin-konflikt?
Alle disse hypotesene må bevises eller motbevises.
Jeg hadde jo ikke så mye å gå etter. Alt jeg visste var at nettleseren viste fram en side som var helt hvit. Eller det vi på fagspråket kaller «White Screen of Death». Dette er egentlig bra. Kunden, eller de som laget nettstedet i første omgang, hadde satt opp nettstedet til ikke å vise fram feilmeldinger.
Ofte skyldes slike feil at driftsselskapet har oppgradert serveren til en nyere PHP-versjon, mens nettstedet fortsatt inneholder gammel kode eller gamle utvidelser.
Men kunne det være tilfellet for dette nettstedet? Svaret får du lenger nede i artikkelen.
Fra virkeligheten
Denne artikkelen bygger på en faktisk kundesak. Enkelte detaljer er anonymisert, men feilsøkingen og løsningen er beskrevet slik den ble gjennomført.
Jeg får nettstedet til å kjøre på lokal maskin
Før jeg gjorde én eneste endring på kundens server, satte jeg opp nettstedet lokalt. Da kunne jeg feilsøke uten risiko for å gjøre situasjonen verre eller gjøre nettstedet utilgjengelig mens jeg jobbet.
Med en lokal versjon av nettstedet kunne jeg sette opp WordPress til å logge og å vise fram feilmeldinger på skjermen. Å vise feilmeldinger er noe du ikke vil gjøre i et produksjonsmiljø. Da avslører du overfor besøkende som har alt annet enn hederlige hensikter hvordan strukturen på nettsiden er. Du kan i verste falle også avsløre brukernavn og passord.
Når jeg kjører WordPress lokalt bruker jeg et verktøy som heter Local som er utviklet av Flywheel. Det finnes andre løsninger som gjør akkurat det samme. Hvis du kjenner til noen av disse, bruker du det verktøyet du har mest erfaring med.
Jeg gjør alltid dette først. Da kan jeg feilsøke uten risiko for å gjøre situasjonen verre på kundens produksjonsserver.
Da får jeg også avdekket en ting – om PHP-versjonen eller WordPress-versjonen er årsaken til at nettstedet hadde krasjet. Det betyr også at jeg kan stryke én eller flere av hypotesene mine.
Feilsøkingen begynner
Når du har fått siden til å kjøre er neste steg å finne ut hvorfor nettstedet ikke virker lenger. En vanlig måte i WordPress er å skru av alle utvidelser (plugins) slik at siden kommer opp igjen. Så skrur du på en og en utvidelse og sjekker om siden fortsatt virker, eller om den krasjet. Når du finner utvidelsen som ikke lenger virker, forsøker du å oppdatere den.
En annen måte er å sjekke logger. Det er alltid lurt å sette på logging i WordPress, særlig når det handler om feilsøking. Da får du se feilmeldingene og du får se hvilken fil det er som feiler.
Den første metoden passer for deg som ikke har teknisk kompetanse til å løse problemet ved å jobbe direkte i PHP-koden. Den andre metoden passer for deg som leser log-filer daglig (slik jeg gjør …) og som har kompetanse til å løse problemet ved å bruke PHP.
Uansett hvilken metode du bruker, er dette steget den tidkrevende delen av å reparere en WordPress-nettside som har sluttet å virke, eller som er «låst» som var ordet kunden brukte.
Problemet er funnet, nå kan du løse det
Når du har funnet problemet er det «bare» å løse problemet. Tidsmessig tar dette langt kortere tid enn å finne problemet. For nå vet du hva problemet er.
Som jeg nevnte innledningsvis, var den største utfordringen å finne feilen. Selve reparasjonen tok bare noen minutter.
For min kunde var problemet at utvidelsen CKEditor var utdatert. Den versjonen som var installert støttet ikke nyere versjoner av PHP. Dette er ganske vanlig. At nettstedet var satt opp med denne editoren var et tydelig bevis på at nettstedet var gammelt. Med nyere versjon av WordPress installert var det ikke lenger behov for denne utvidelsen, så jeg fjernet den rett og slett.
Etter å ha avinstallert utvidelsen gikk jeg over hele nettstedet for å sjekke at jeg ikke hadde brukket noe – altså laget en ny feil.
Opprydding
Som et siste steg før jeg flyttet løsningen tilbake i produksjon var å rydde opp i løsningen. Underveis i testingen merket jeg at det ikke var behov for mange av utvidelsene som var installert.
Jeg fjernet derfor flere utvidelser som ikke lenger var i bruk. Færre utvidelser betyr mindre vedlikehold og færre mulige feilkilder i fremtiden.
Lærdom
Grunnen til at kunden fikk dette problemet var fordi nettstedet var utviklet for mange år siden. Utvidelsen hadde fått lov til å bli med etter hvert som WordPress ble oppdatert. I mange år gikk dette bra. Helt til det ikke gjorde det lenger. Og da hadde heller ikke kunden noen kontaktperson å ringe til lenger.
Det er vanlig å si at en fem år gammel nettside bør oppgraderes. Ikke bare utseendemessig, men også teknisk. Jeg vil faktisk mene at du bør oppdatere nettstedet ditt teknisk så ofte som mulig. Dette gjelder selve kjernen i WordPress og ikke minst utvidelsene.
Som utvikler av nettsteder med bruk av WordPress passer jeg på at utvidelsene er jevnlig oppdatert. Dersom jeg ser at en utvidelse henger etter i forhold til siste versjon av WordPress, vurderer jeg om denne utvidelsen trengs i det hele tatt, eller om det finnes andre alternativer.
Hva koster det å redde en WordPress-side som har krasjet?
Jeg gir aldri pris på å redde WordPress-sider. Grunnen er at det å finne ut hvorfor ditt nettsted har krasjet tar tid. Noen ganger tar det også tid å rette filen. Løsningen kan være alt fra å oppdatere en utvidelse, til rett og slett rette svært gammel spesialutviklet kode for deres nettsted.
I tilfellet over brukte jeg flere timer på feilsøking og noen minutter på å rette feilen.
Hvis nettstedet ditt plutselig viser en hvit skjerm, ikke lar deg logge inn eller oppfører seg annerledes enn før, kan jeg hjelpe deg med feilsøking. Jeg lover ikke at feilen er løst på ti minutter. Men jeg lover å finne ut hva som faktisk er galt.
