Selv om WordPress er en relativt trygg plattform med færre feil enn i typisk programvareutvikling, finnes det alltid muligheter for problemer å snike seg inn.
En generell regel er at jo mer fleksibelt et verktøy er, desto flere potensielle feil kan oppstå.
WordPress er svært fleksibelt, og dermed er det mange potensielle feilkilder. Du kan utvide funksjonaliteten med plugins, du har en webserver, en hosting-leverandør, et databasesystem og et nettverk. Alle disse elementene er uavhengige og bidrar til den totale risikoen for feil.
Problemer kan variere fra treg ytelse, feilaktig eller ødelagt innhold, feilmeldinger, og i verste fall: «White Screen of Death» (WSoD), som betyr at nettsiden din har krasjet og krever umiddelbar oppmerksomhet.
Selv en liten forsinkelse – for eksempel på mindre enn to sekunder – er bekymringsverdig da det kan (og vil) påvirke din SEO-strategi og plassering i søkeresultatene negativt. Dette kan føre til færre besøkende dag for dag, da rask respons er avgjørende, spesielt for mobilbrukere.
Det er derfor viktig å ha verktøy tilgjengelig når du opplever at nettsiden ikke fungerer som den skal. Og selv om den gjør det, er det alltid rom for å forbedre ytelsen eller brukervennligheten.
Hva er feilsøking?
Feilsøking er prosessen utviklere bruker for å finne og fjerne feil (bugs) fra sine programmer. Dette gjøres med spesialiserte verktøy som lar deg se hva som skjer inne i et program under kjøring.
Noen ganger er det vanskeligste med feilsøkingen å identifisere den eksakte komponenten, kommandoen eller instruksjonen som forårsaker feilen. For å gjøre dette, analyserer utviklere symptomene og utfører nødvendige undersøkelser for å identifisere årsaken, akkurat som en lege. I programvareutvikling tilsvarer dette overvåkingsverktøy som gir informasjon om en nettsides indre funksjon.
La oss se på noen alternativer.
WP_DEBUG
WordPress har en innebygd feilsøkingsfunksjon som ofte blir oversett. Det er et «flagg» kalt WP_DEBUG som aktiverer feilsøkingsmodus i WordPress. Når WP_DEBUG er aktivert, opprettes en logg som registrerer all aktivitet på nettsiden din. Ved å lese denne loggen kan du finne ut hva som ikke fungerer som det skal.
For å aktivere WP_DEBUG, må du gjøre noen endringer i wp-config.php-filen og legge til de nødvendige kodelinjene for å instruere nettsiden din til å logge all aktivitet. Vær forsiktig når du redigerer wp-config.php-filen, da feil plassering av en linje eller et tegn kan føre til at nettsiden din slutter å fungere. Ta en sikkerhetskopi av nettsiden/filene dine før du gjør endringer. Hvis noe går galt, kan du gjenopprette sikkerhetskopien og tilbakestille alt.
For å redigere wp-config.php-filen, bruk filbehandleren til hosting-leverandøren din eller en FTP-klient for å laste ned filen og åpne den lokalt med et tekstredigeringsprogram. Filen ligger i hovedkatalogen til din WordPress-installasjon. Finn linjen der WP_DEBUG er definert. Den vil se slik ut:
define( 'WP_DEBUG', false );
Hvis det ikke finnes en slik linje, se etter følgende kommentar:
/* That’s all, stop editing! Happy blogging. */
og legg til følgende linjer over kommentaren. Disse kommandoene vil instruere nettsiden din til å logge alle feil uten å vise dem, noe som er nyttig for offentlig tilgjengelige nettsider:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
Lagre filen, og hvis du bruker FTP, last den opp til nettsiden din. Prøv deretter å provosere feilen (eller vent til den skjer) og sjekk filen debug.log. Du finner den i wp-innholdsmappen i din WordPress-installasjon. Du kan åpne den med et tekstredigeringsprogram og se etter feilmeldingene som avslører hva som forårsaker problemer på nettsiden din.
Etter å ha gjort dette, bør du deaktivere logging ved å endre verdiene «true» til «false» i alle linjene du la til eller endret i wp-config.php-filen.
WPDB-feilrapportering
Hvis du mistenker at databasen til nettsiden din forårsaker problemer, kan du aktivere WPDB-feilrapportering. Dette krever også litt koding. Når du har aktivert feilrapportering, kan du instruere nettsiden din til å vise databasefeil på skjermen.
Dette bør ikke gjøres på en live nettside med mindre du ikke bryr deg om at besøkende ser feilmeldinger. Det er bedre å bruke en testside (som beskrevet nedenfor) der du kan teste uten å la alle se hva som skjer.
Å lese feilrapportene eller loggene krever litt teknisk kunnskap, på samme måte som medisinsk kunnskap er nødvendig for å lese et røntgenbilde. Du må tolke programmerings-, nettverks- eller databasesjargong, men du vil sannsynligvis finne rotproblemet som påvirker nettsiden din, og deretter få hjelp fra noen som kan løse det spesifikke problemet.
For å begynne å generere databasefeilrapporter, legg til følgende linje i wp-config.php-filen (på samme måte som forklart tidligere for å generere feilsøkingsloggen):
define( 'SAVEQUERIES', true);
Når denne verdien er satt til sann, vil databasen begynne å lagre alle søk på nettsiden din. Deretter kan du inspisere antall søk forårsaket av hver sideforespørsel og kommandoene som brukes i hver. En måte å vise spørringene på skjermen er å legge til disse linjene i PHP-temaet ditt:
global $wpdb; print_r( $wpdb->queries );
Når du er ferdig med feilsøkingen, bør du fjerne disse linjene for å gjenopprette nettsiden til normal drift.
Ved hjelp av en testside
En testside er en klone av din faktiske nettside, der du kan teste endringer eller nye funksjoner før du lanserer dem. Det er også en god idé å bruke en testside for å feilsøke problemer eller overvåke oppførselen, da det gir deg friheten til å prøve alt uten å forstyrre de faktiske brukerne av nettsiden din.
Det er viktig at en testside nøyaktig gjenspeiler innholdet og strukturen til din faktiske nettside. Hver gang du oppdaterer WordPress-nettsiden din med nytt innhold eller nye tillegg (for det meste plugins og temaer), bør du oppdatere testsiden din med en kopi av den faktiske. På denne måten, hvis det oppstår et problem på live-nettsiden, vil du kunne gjenskape det på testmiljøet.
Mange administrerte WordPress-hosting-leverandører tilbyr en testside som en merverdi til sine betalte planer. Dette er den mest brukervennlige måten å ha et testmiljø hvor du kan eksperimentere uten risiko. Men hvis din hosting-leverandør ikke tilbyr denne muligheten, kan du opprette en testside ved å bruke WP Staging-pluginet. Dette pluginet gjør det enkelt å klone nettsiden din og deretter bruke klonen som om den var ekte. Du vil alltid vite når du er i testmiljøet, da en oransje stripe øverst på skjermen vil indikere dette.
Hvis du foretrekker å gjøre det manuelt, kan du alltid opprette en testside på et underdomene, forutsatt at hosting-leverandøren din tillater deg å legge til et underdomene til kontoen din. Prosessen med å lage en testside på denne måten kan være litt komplisert, så hvis du er nybegynner i WordPress, kan det være lurt å bruke et annet alternativ.
Spørremonitor
Navnet kan være misvisende, da Spørremonitor gjør mye mer enn bare å overvåke spørringer. Det er et komplett utviklerpanel for WordPress, som gir deg mulighet til å feilsøke skript, stilark, API-kall, databasespørringer, PHP-feil og mer. Noen avanserte funksjoner lar deg feilsøke Ajax-samtaler og sjekke ytelsen.
Når du har installert og aktivert det, vil Query Monitor begynne å vise informasjon om nettsidens oppførsel på de mest nyttige måtene.
Den viser for eksempel samlede databasespørringer gruppert etter funksjonene, pluginene eller temaene som utløste dem. En verktøylinje for admin viser sanntidsstatistikk for gjeldende side, med all feilsøkingsinformasjon du trenger for å evaluere problemet du skal løse.
Ved hjelp av Query Monitor kan du gradvis begrense søket etter feil etter plugin eller tema, til du finner den som påvirker ytelsen til nettsiden din eller forårsaker funksjonsfeil. I likhet med WordPress er Query Monitor helt gratis og åpen kildekode.
Tidligere kjent som Firebug, Firefox utviklerverktøy er en spesialversjon av Firefox tilpasset utviklere, og tilbyr de nyeste utviklingsfunksjonene og verktøyene. Det er ikke spesifikt for WordPress, men det viser seg å være svært nyttig for feilsøking av nettsider.
Det er naturlig å sammenligne Firefox Developer Tools med de mer populære Chrome DevTools. Når du gjør det, skiller Firefoxs oversiktlighet seg ut. Du kan for eksempel høyreklikke på et hvilket som helst element for å åpne inspektørfanen, og nettkonsollen gir mer detaljert utdata når du skriver ut objekter, og viser mye mer informasjon enn bare navnet. Det gir ekstra informasjon for visse typer, muliggjør en grundig undersøkelse av objektets egenskaper og gir mer rikholdig informasjon for DOM-elementer.
Med Inspector-verktøyet kan du undersøke og endre side-HTML og CSS, enten på sider som er lastet lokalt i Firefox eller på en ekstern enhet, som Firefox for Android.
Nettkonsollen viser all informasjon du trenger om en nettside: JavaScript, nettverksforespørsler, CSS, advarsler, feilmeldinger og informasjonsmeldinger som er logget eksplisitt med JavaScript-kode. Den lar deg også samhandle med en nettside ved å kjøre JavaScript-uttrykk direkte i sidekonteksten.
New Relic
Som en av de største aktørene innen APM (Application Performance Monitoring), er New Relic et kommersielt produkt som brukes av tusenvis av utviklere over hele verden for å få innsikt i ytelsen til programvareproduktene sine. Det har en plugin-arkitektur som gir mulighet for ekstra funksjonalitet fra tredjeparter, som resulterer i et nesten uendelig utvalg av teknologier som kan overvåkes av dette verktøyet.
Med en pris fra $9,37 til $200 per server per måned, er det beregnet for profesjonelle feilsøkingsoppgaver. Det har også en bratt læringskurve, så i tillegg til å betale for løsningen, må du også investere tid i å lære å bruke den. Brukere av New Relic setter pris på at det enkelt integreres i applikasjoner for APM og infrastrukturovervåking.
Kinsta lar deg enkelt integrere New Relic fra deres MyKinsta-dashbord.
Feilsøkingslinje
Feilsøkingslinje er et sett med plugins som er tilgjengelige via en feilsøkingsmeny på WordPress-administrasjonslinjen, og viser et bredt utvalg av feilsøkingsinformasjon. Alternativene inkluderer konsoll, kortkoder, konstanter, posttyper, cron, handlinger og filtre, transienter, eksterne forespørsler og liste over skript- og stilavhengigheter. Det er en åpen kildekode-plugin, så den er gratis å bruke.
Hovedpluginet, Debug Bar, gir grunnfunksjonaliteten, utvidet med resten av pluginene. Den fungerer med de innebygde feilsøkingsflaggene som tilbys av WordPress, for eksempel WP_DEBUG og SAVEQUERIES. Når disse flaggene er aktive, legger Debug Bar til nyttig feilsøkingsinformasjon, for eksempel PHP-advarsler og MySQL-spørringer, slik at du slipper å lete etter og lese loggfilene.
Hvert alternativ i feilsøkingslinjen gir sin del av feilsøkingsmulighetene. For eksempel gir konsollen en konsoll der du kan kjøre vilkårlig PHP-kode, noe som er utmerket for å teste innholdet i variabler (blant annet). Cron viser informasjon om WordPress’ planlagte hendelser, for eksempel tidspunkt for neste hendelse, antall planlagte hendelser, listen over egendefinerte planlagte hendelser osv. Handlinger og filtre er et annet alternativ for å vise kroker knyttet til gjeldende forespørsel. Handlinger-fanen viser handlingene som er koblet til gjeldende forespørsel, mens filtre-fanen viser alle filtertagger, sammen med funksjonene knyttet til hver enkelt.
Feilsøking for alle
Feilsøkingsverktøy er for det meste designet for profesjonelle programvareutviklere. Men selv om du ikke er utvikler og bare vedlikeholder en WordPress-blogg, er det nyttig å ha grunnleggende kunnskap om hvordan du overvåker og feilsøker nettsiden din. Ved å gjøre det, kan du gi en utvikler verdifull informasjon som hjelper ham eller henne med å finne kilden til et problem. Og hvis du føler deg syk, kan du spare legen din for litt arbeid ved å ta temperaturen selv før du drar til sykehuset.
Lær hvordan du kan tjene penger som WordPress-profesjonell.