Selv om WordPress er et kontrollert miljø, hvor feil er mye sjeldnere enn i en typisk programvareutviklingssetting, er det alltid et vindu eller en dør som problemer kan krype inn gjennom.
Som hovedregel kan det sies at jo mer fleksibilitet et verktøy gir deg, jo flere potensielle feil kan du støte på.
I det spesielle tilfellet med WordPress er det rikelig med fleksibilitet, og derfor mange potensielle feil. Du har en åpen plugin-arkitektur du kan bruke til å legge til funksjoner i CMS; du har en webserver, en vertsleverandør, et databasestyringssystem og et nettverk. Alle disse komponentene er uavhengige faktorer som bidrar til deres andel av potensielle problemer.
Den typen problemer du kan støte på inkluderer treg ytelse, feil eller skadet innhold, feilmeldinger og, verst av alt: White Screen of Death (WSoD), som betyr at nettstedet ditt har krasjet og krever umiddelbar oppmerksomhet.
Selv et lite ytelsesproblem – for eksempel en forsinkelse på mindre enn 2 sekunder – er noe du bør være bekymret for fordi det kan (og vil) skade SEO-strategien din og posisjoneringen din i søkemotorresultatene. Og det gir direkte færre og færre besøkende hver dag, for i disse dager er rask respons alt, spesielt for mobilbrukere.
Det er derfor det er avgjørende å ha verktøy som du kan bruke når du føler at nettstedet ditt ikke fungerer som det skal. Og selv om den gjør det, er det alltid rom for å forbedre ytelsen eller brukervennligheten.
Hva er feilsøking?
Feilsøking er oppgave utviklere utfører for å oppdage og fjerne feil (også kalt feil) fra programmene deres. Det gjøres ved hjelp av spesialiserte verktøy som lar deg se hva som skjer inne i et program mens det kjøres.
Noen ganger er den vanskeligste delen av feilsøkingsjobben å finne ut den nøyaktige komponenten, kommandoen eller instruksjonen som forårsaker en feil. For å gjøre dette gjør utviklere det samme som en lege som må stille en diagnose: analysere symptomene og, om nødvendig, utføre noen studier for å identifisere kilden til problemet. Programvareutvikling som tilsvarer medisinske studier er et overvåkingsverktøy som gir informasjon om en nettsides indre funksjon.
La oss se noen alternativer.
Innholdsfortegnelse
WP_DEBUG
WordPress har en innebygd feilsøkingshjelp som ofte blir oversett. Det er et «flagg» kalt WP_DEBUG som utløser feilsøkingsmodusen i WordPress når den aktiveres. Når du aktiverer WP_DEBUG, genereres en logg som registrerer all aktiviteten til nettstedet ditt. Ved å lese denne loggen kan du finne ut hva som ikke fungerer som det skal på WordPress-nettstedet ditt.
For å slå på WP_DEBUG, må du gjøre litt koding, ved å redigere wp-config.php-filen og legge til de nødvendige linjene for å beordre nettstedet ditt til å registrere all aktivitet i loggen. Denne kodingsoppgaven er ikke for alle: du må være veldig forsiktig når du redigerer filen wp-config.php, fordi hvis du feilplasserer en linje eller til og med et tegn, kan nettstedet ditt slutte å fungere. Ta også en sikkerhetskopi av nettstedet/filene dine før du gjør noe. Hvis du roter til ting, kan du gjenopprette sikkerhetskopien og rulle alt tilbake til det normale.
For å redigere filen wp-config.php, bruk filbehandleren til vertsleverandøren din eller bruk en FTP-klient for å laste ned filen og åpne den lokalt med ditt foretrukne tekstredigeringsprogram. Filen ligger i hovedkatalogen til WordPress-installasjonen din. Etter at du har åpnet den, finn linjen der WP_DEBUG er definert. Det skal se slik ut:
define( 'WP_DEBUG', false );
Hvis det ikke er en slik linje, søk etter følgende kommentar:
/* That’s all, stop editing! Happy blogging. */
og legg til følgende linjer over kommentaren. Disse kommandoene vil instruere nettstedet ditt til å logge alle feil uten å vise dem, noe som er nyttig for nettsteder som er offentlig tilgjengelig:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
Lagre den endrede filen, og hvis du bruker FTP, last den opp til nettstedet ditt. Prøv deretter å provosere feilen (eller vent til den skjer) og sjekk filen debug.log. Du finner den i wp-innholdsmappen til WordPress-installasjonen din. Du kan åpne den med et tekstredigeringsprogram og se etter feilmeldingene som avslører hva som forårsaker problemer på nettstedet ditt.
Etter å ha gjort dette, bør du slå av logging ved å endre verdiene «true» til «false» i alle linjene du la til eller endret i filen wp-config.php.
WPDB-feilrapportering
Hvis du vet eller mistenker at databasen til nettstedet ditt forårsaker problemer, kan du aktivere WPDB-feilrapportering. Dette krever også noe koding. Når du har aktivert feilrapportering, kan du instruere nettstedet ditt til å begynne å vise databasefeil på skjermen.
Du bør ikke gjøre dette på et live nettsted med mindre du ikke bryr deg om de besøkende får feilmeldinger på skjermene sine. Det er bedre å bruke et iscenesettelsesnettsted (som beskrevet nedenfor) hvor du kan teste alt du vil uten å la alle se hva som skjer under panseret.
Å lese disse feilrapportene eller loggene krever litt teknisk kunnskap, akkurat som det krever medisinsk kunnskap for å lese et røntgenbilde, for eksempel. Du må dechiffrere noe programmerings-, nettverks- eller databasesjargong, men du finner sannsynligvis rotproblemet som påvirker nettstedet ditt, 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 før for å generere feilsøkingsloggen):
define( 'SAVEQUERIES', true);
Ved å sette denne verdien til sann, vil databasen begynne å lagre alle søk på nettstedet ditt. Deretter vil du kunne inspisere antall søk forårsaket av hver sideforespørsel og kommandoene som brukes i hver enkelt. En måte å vise spørringene på skjermen er å legge til disse linjene i PHP-tema-filen din i utførelsesflyten din:
global $wpdb; print_r( $wpdb->queries );
Når du er ferdig med feilsøkingen, bør du fjerne disse linjene for å gjenopprette nettstedet til normal drift.
Ved hjelp av et iscenesettelsesnettsted
Et iscenesettelsesnettsted er en klone av det faktiske nettstedet ditt, hvor du kan teste endringer eller nye funksjoner før du går live med dem. Det er også en god idé å bruke et iscenesettelsesnettsted for å feilsøke problemer eller overvåke dets oppførsel, fordi det gir deg friheten til å prøve ut alt du vil uten å forstyrre de faktiske brukerne av nettstedet ditt.
Det er viktig at et iscenesettelsesnettsted gjenspeiler nøyaktig innholdet og strukturen til ditt faktiske nettsted. Hver gang du oppdaterer WordPress-nettstedet ditt med nytt innhold eller nye tillegg (for det meste plugins og temaer), bør du oppdatere iscenesettelsen din med en kopi av den faktiske. På denne måten, hvis det oppstår et problem på live-nettstedet ditt, vil du kunne replikere det på scenemiljøet ditt.
Mange administrerte WordPress-vertsleverandører tilbyr et oppsamlingsnettsted som en merverdi til deres betalte planer. Dette er den mest brukervennlige måten å ha et iscenesettelsesmiljø hvor du kan spille og prøve ting uten risiko. Men hvis vertsleverandøren din ikke tilbyr deg denne muligheten, kan du opprette en oppsamlingsside ved å bruke WP Staging plugg inn. Dette pluginet gjør det enkelt å klone nettstedet ditt og deretter bruke klonen som om den var ekte vare. Du vil alltid vite når du er i scenemiljøet fordi en oransje stolpe øverst på skjermen vil fortelle deg det.
Hvis du liker å bli skitne til hendene, kan du alltid opprette et oppsamlingssted manuelt på et underdomene, forutsatt at vertsleverandøren din lar deg legge til et underdomene til kontoen din. Prosessen med å lage iscenesettelsen på denne måten kan være litt vanskelig, så hvis du er en WordPress-nybegynner, kan det være lurt å bruke et annet alternativ.
Spørremonitor
Navnet kan være misvisende fordi Spørremonitor gjør mye mer enn bare å overvåke spørringer. Det er et komplett utviklerpanel for WordPress, som muliggjør feilsøking av skript, stilark, API-kall, databasespørringer, PHP-feil og mer. Noen avanserte funksjoner lar deg feilsøke Ajax-samtaler og sjekke brukerevnen.
Når du har installert og aktivert det, begynner Query Monitor å vise informasjon om nettstedets oppførsel på de mest nyttige måtene.
For eksempel viser den samlede databasespørringer gruppert etter funksjonene, pluginene eller temaene som utløste dem. En admin-verktøylinjemeny viser live-statistikk for gjeldende side, med all feilsøkingsinformasjonen du måtte trenge for å vurdere problemet du må løse.
Ved å bruke Query Monitor kan du gradvis begrense søket etter feil etter plugin eller tema, til du finner den som forringer ytelsen til nettstedet ditt eller forårsaker en funksjonsfeil. Akkurat som WordPress, er Query Monitor helt gratis og åpen kildekode.
Tidligere kjent som Firebug, Firefox utviklerverktøy er en spesialversjon av Firefox skreddersydd for utviklere, og tilbyr de nyeste utviklingsfunksjonene og verktøyene. Det er ikke spesifikt for WordPress, men det viser seg å være veldig nyttig for feilsøking av nettsteder.
Det er uunngåelig å sammenligne Firefox Developer Tools med de mer populære Chrome DevTools. Når du gjør det, skiller Firefoxs solide layout seg ut. Du kan for eksempel høyreklikke på et hvilket som helst element for å trekke opp inspektørfanen, og nettkonsollen tilbyr rike 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 detaljert undersøkelse av objektets egenskaper og gir rikere informasjon for DOM-elementer.
Med Inspector-verktøyet kan du undersøke og endre side-HTML og CSS, slik at du kan gjøre det med sider som er lastet lokalt på Firefox eller på en ekstern enhet, som Firefox for Android.
Nettkonsollen viser all informasjonen du måtte trenge om en nettside: JavaScript, nettverksforespørsler, CSS, advarsler, feilmeldinger og informasjonsmeldinger som er eksplisitt logget med JavaScript-kode. Den lar deg også samhandle med en nettside ved å kjøre JavaScript-uttrykk direkte i sidekonteksten.
Ny relikvie
Som en av de største aktørene i APM (Application Performance Monitoring) industrien, Ny relikvie er et kommersielt produkt som tusenvis av utviklere verden over bruker på daglig basis for å få ytelsesinnsikt om programvareproduktene deres. Den har en plugin-arkitektur som gir mulighet for ekstra funksjonalitet av tredjeparter, noe som resulterer i et praktisk talt uendelig spekter av teknologier som kan overvåkes av dette verktøyet.
Med en prisklasse fra $ 9,37 til $ 200 per vert per måned, er den beregnet på profesjonelle feilsøkingsoppgaver. Den har også en utvidet læringskurve, så i tillegg til å bruke penger på løsningen, må du også investere tid for å lære å bruke den. Brukere av New Relic setter pris på det faktum at det enkelt integreres i applikasjoner for APM og infrastrukturovervåking.
Kinsta lar deg enkelt integrere New Relic fra MyKinsta-dashbordet deres.
Feilsøkingslinje
Feilsøkingslinje er et sett med plugins tilgjengelig via en feilsøkingsmeny på WordPress-administrasjonslinjen, som viser et bredt utvalg av feilsøkingsinformasjon. Alternativene inkluderer konsollen, kortkoder, konstanter, posttyper, cron, handlinger og filtre, transienter, eksterne forespørsler og listeskript og stilavhengigheter. Det er en åpen kildekode-plugin, så den kan brukes gratis.
Hovedpluginen, Debug Bar, gir basisfunksjonaliteten, utvidet med resten av pluginene. Det 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, og sparer deg for bryet med å lete etter og lese loggfilene.
Hvert alternativ i feilsøkingslinjen gir sin andel av feilsøkingskraften. Konsollen gir for eksempel en konsoll der du kan kjøre vilkårlig PHP-kode, som er utmerket for å teste innholdet i variabler (blant annet bruk). Cron viser informasjon om WordPresss 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 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 en utvikler, hvis du bare vedlikeholder en WordPress-blogg, er det nyttig å ha minst en grunnleggende kunnskap om hvordan du overvåker og feilsøker nettstedet ditt. Ved å gjøre det kan du gi en utvikler informasjon som vil hjelpe ham eller henne å finne kilden til et problem, samtidig som du, hvis du føler deg dårlig, kan spare legen din for litt arbeid ved å ta temperaturen selv før du drar til sykehuset.
Lær noen måter å tjene penger på som WordPress-profesjonell.