Selvom WordPress er et kontrolleret miljø, hvor fejl er meget sjældnere end i en typisk softwareudviklingsindstilling, er der altid et vindue eller en dør, hvorigennem problemer kan kravle ind.
Som hovedregel kan man sige, at jo mere fleksibilitet et værktøj giver dig, jo flere potentielle fejl kan du støde på.
I det særlige tilfælde med WordPress er der masser af fleksibilitet og derfor masser af potentielle fejl. Du har en åben plugin-arkitektur, du kan bruge til at tilføje funktioner til CMS; du har en webserver, en hostingudbyder, et databasestyringssystem og et netværk. Alle disse komponenter er uafhængige faktorer, der bidrager til deres andel af potentielle problemer.
Den slags problemer, du kan støde på, omfatter langsom ydeevne, forkert eller beskadiget indhold, fejlmeddelelser og, værst af alt: den hvide skærm af død (WSoD), som betyder, at dit websted er gået ned og kræver øjeblikkelig opmærksomhed.
Selv et lille ydelsesproblem – såsom en forsinkelse på mindre end 2 sekunder – er noget, du bør være bekymret over, fordi det kan (og vil) skade din SEO-strategi og din placering i søgemaskineresultaterne. Og det udmønter sig direkte i færre og færre besøgende hver dag, for i disse dage er et hurtigt svar alt, især for mobilbrugere.
Derfor er det afgørende at have værktøjer, som du kan bruge, når du føler, at dit websted ikke fungerer korrekt. Og selvom den gør det, er der altid plads til at forbedre dens ydeevne eller brugervenlighed.
Hvad er debugging?
Debugging er opgaveudviklere, der udfører for at opdage og fjerne fejl (også kaldet fejl) fra deres programmer. Det gøres ved hjælp af specialiserede værktøjer, der lader dig se, hvad der foregår inde i et program, mens det kører.
Nogle gange er den sværeste del af fejlfindingsopgaven at finde ud af den præcise komponent, kommando eller instruktion, der forårsager en fejl. For at gøre dette gør udviklere det samme som en læge, der skal stille en diagnose: analysere symptomerne og om nødvendigt udføre nogle undersøgelser for at identificere kilden til problemet. Softwareudvikling, der svarer til medicinske studier, er et overvågningsværktøj, der giver information om et websteds indre funktioner.
Lad os se nogle muligheder.
Indholdsfortegnelse
WP_DEBUG
WordPress har en indbygget fejlfindingshjælp, som ofte overses. Det er et “flag” kaldet WP_DEBUG, der udløser fejlretningstilstanden i WordPress, når den aktiveres. Når du aktiverer WP_DEBUG, genereres en log, der registrerer al din hjemmesides aktivitet. Ved at læse denne log kan du finde ud af, hvad der ikke fungerer korrekt på dit WordPress-websted.
For at slå WP_DEBUG til, skal du lave noget kodning ved at redigere din wp-config.php-fil og tilføje de nødvendige linjer for at beordre dit websted til at registrere al aktivitet i loggen. Denne kodningsopgave er ikke for alle: du skal være meget forsigtig, når du redigerer filen wp-config.php, for hvis du fejlplacerer en linje eller endda et tegn, kan dit websted holde op med at fungere. Lav også en sikkerhedskopi af dit websted/filer, før du gør noget. Hvis du roder tingene sammen, kan du gendanne sikkerhedskopien og rulle alt tilbage til det normale.
For at redigere filen wp-config.php skal du bruge din hostingudbyders filhåndtering eller bruge en FTP-klient til at downloade filen og åbne den lokalt med din foretrukne teksteditor. Filen er placeret i hovedbiblioteket i din WordPress-installation. Når du har åbnet det, skal du finde linjen, hvor WP_DEBUG er defineret. Det skal se sådan ud:
define( 'WP_DEBUG', false );
Hvis der ikke er en sådan linje, søg efter følgende kommentar:
/* That’s all, stop editing! Happy blogging. */
og tilføj følgende linjer over denne kommentar. Disse kommandoer vil instruere dit websted om at logge alle fejl uden at vise dem, hvilket er nyttigt for websteder, der er offentligt tilgængelige:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
Gem den ændrede fil, og upload den til dit websted, hvis du bruger FTP. Prøv derefter at fremprovokere fejlen (eller vent til den sker) og tjek filen debug.log. Du finder det i mappen wp-content i din WordPress-installation. Du kan åbne den med en teksteditor og se efter de fejlmeddelelser, der afslører, hvad der forårsager problemer på din hjemmeside.
Efter at have gjort dette, bør du slå logning fra ved at ændre værdierne “true” til “false” i alle de linjer, du tilføjede eller ændrede i filen wp-config.php.
WPDB-fejlrapportering
Hvis du ved eller har mistanke om, at dit websteds database forårsager problemer, kan du aktivere WPDB-fejlrapportering. Dette kræver også noget kodning. Når du har aktiveret fejlrapportering, kan du instruere dit websted i at begynde at vise databasefejl på skærmen.
Du bør ikke gøre dette på en live hjemmeside, medmindre du er ligeglad med, om dine besøgende får fejlmeddelelser på deres skærme. Det er bedre at bruge et iscenesættelseswebsted (som beskrevet nedenfor), hvor du kan teste alt, hvad du vil, uden at lade alle se, hvad der sker under motorhjelmen.
At læse disse fejlrapporter eller logfiler kræver en vis teknisk viden, ligesom det kræver medicinsk viden at læse et røntgenbillede, for eksempel. Du bliver nødt til at tyde noget programmerings-, netværks- eller databasejargon, men du finder sandsynligvis rodproblemet, der påvirker dit websted, og får derefter hjælp fra nogen, der kan løse det specifikke problem.
For at begynde at generere databasefejlrapporter skal du tilføje følgende linje til din wp-config.php-fil (på samme måde som forklaret før for at generere fejlfindingsloggen):
define( 'SAVEQUERIES', true);
Ved at indstille denne værdi til sand, begynder databasen at gemme alle forespørgsler, dit websted foretager. Så vil du være i stand til at inspicere antallet af forespørgsler forårsaget af hver sideanmodning og de kommandoer, der bruges i hver enkelt. En måde at vise forespørgslerne på på skærmen er at tilføje disse linjer i din PHP-tema-fil i dit udførelsesflow:
global $wpdb; print_r( $wpdb->queries );
Når du er færdig med fejlretningen, bør du fjerne disse linjer for at gendanne dit websted tilbage til dets normale drift.
Brug af et iscenesættelseswebsted
Et iscenesættelseswebsted er en klon af dit faktiske websted, hvor du kan teste ændringer eller nye funktioner, før du går live med dem. Det er også en god idé at bruge et iscenesættelseswebsted til at fejlsøge problemer eller overvåge dets adfærd, fordi det giver dig frihed til at prøve alt, hvad du vil, uden at forstyrre de faktiske brugere af dit websted.
Det er vigtigt, at et iscenesættelseswebsite afspejler præcis indholdet og strukturen på din aktuelle hjemmeside. Hver gang du opdaterer dit WordPress-websted med nyt indhold eller nye tilføjelser (for det meste plugins og temaer), bør du opdatere din iscenesættelsesside med en kopi af den faktiske. På denne måde, hvis der opstår et problem på dit live-websted, vil du være i stand til at replikere det på dit iscenesættelsesmiljø.
Mange administrerede WordPress-hostingudbydere tilbyder et iscenesættelsessted som en merværdi til deres betalte planer. Dette er den mest brugervenlige måde at have et iscenesættelsesmiljø, hvor du kan spille og prøve ting uden risiko. Men hvis din hostingudbyder ikke tilbyder dig denne mulighed, kan du oprette et mellemstation ved hjælp af WP Staging plugin. Dette plugin gør det nemt at klone dit websted og derefter bruge klonen, som om den var den ægte vare. Du vil altid vide, hvornår du er i scenemiljøet, fordi en orange bjælke øverst på skærmen vil fortælle dig det.
Hvis du nyder at få dine hænder beskidte, kan du altid oprette et iscenesættelsessted manuelt på et underdomæne, forudsat at din hostingudbyder lader dig tilføje et underdomæne til din konto. Processen med at oprette iscenesættelsesstedet på denne måde kan være lidt vanskelig, så hvis du er en WordPress-begynder, vil du måske bruge en anden mulighed.
Forespørgselsovervågning
Dens navn kan være vildledende pga Forespørgselsovervågning gør meget mere end blot at overvåge forespørgsler. Det er et komplet udviklerpanel til WordPress, der muliggør fejlretning af scripts, stylesheets, API-kald, databaseforespørgsler, PHP-fejl og mere. Nogle avancerede funktioner giver dig mulighed for at fejlsøge Ajax-opkald og foretage kontrol af brugerkapacitet.
Når du har installeret og aktiveret det, begynder Query Monitor at vise oplysninger om dit websteds adfærd på de mest nyttige måder.
For eksempel viser den samlede databaseforespørgsler grupperet efter de funktioner, plugins eller temaer, der udløste dem. En admin-værktøjslinjemenu viser live-statistikker for den aktuelle side med al den fejlretningsinformation, du muligvis har brug for for at vurdere det problem, du skal løse.
Ved at bruge Query Monitor kan du indsnævre din søgning gradvist efter fejl efter plugin eller tema, indtil du finder den, der forringer dit websteds ydeevne eller forårsager en funktionsfejl. Ligesom WordPress er Query Monitor fuldstændig gratis og open source.
Tidligere kendt som Firebug, Firefox udviklerværktøjer er en speciel version af Firefox, der er skræddersyet til udviklere, og som tilbyder de nyeste udviklingsfunktioner og værktøjer. Det er ikke specifikt for WordPress, men det viser sig at være meget nyttigt til fejlfinding af hjemmesider.
Det er uundgåeligt at sammenligne Firefox Developer Tools med de mere populære Chrome DevTools. Når du gør det, skiller Firefoxs solide layout sig ud. For eksempel kan du højreklikke på et hvilket som helst element for at trække inspektørfanen op, og webkonsollen tilbyder et rigt output, når du udskriver objekter, og viser meget mere information end blot dets navn. Det giver ekstra information for visse typer, hvilket muliggør en detaljeret undersøgelse af objektets egenskaber og giver rigere information om DOM-elementer.
Med Inspector-værktøjet kan du undersøge og ændre side-HTML og CSS, så du kan gøre det med sider, der er indlæst lokalt på Firefox eller på en ekstern enhed, som Firefox til Android.
Webkonsollen viser alle de oplysninger, du måtte have brug for om en webside: JavaScript, netværksanmodninger, CSS, advarsler, fejlmeddelelser og informationsmeddelelser, der eksplicit er logget med JavaScript-kode. Det giver dig også mulighed for at interagere med en webside ved direkte at udføre JavaScript-udtryk i sidekonteksten.
Ny relikvie
Som en af de største aktører i APM (Application Performance Monitoring) industrien, Ny relikvie er et kommercielt produkt, som tusindvis af udviklere verden over bruger på daglig basis for at få indsigt i ydeevnen om deres softwareprodukter. Det har en plugin-arkitektur, der giver mulighed for ekstra funktionalitet af tredjeparter, hvilket resulterer i et stort set uendeligt spektrum af teknologier, der kan overvåges af dette værktøj.
Med et prisinterval fra $ 9,37 til $ 200 per vært per måned, er det beregnet til professionelle fejlfindingsopgaver. Den har også en udvidet læringskurve, så udover at bruge penge på løsningen, skal du også investere tid for at lære at bruge den. Brugere af New Relic sætter pris på, at det nemt kan integreres i applikationer til APM og infrastrukturovervågning.
Kinsta lader dig nemt integrere New Relic fra deres MyKinsta-dashboard.
Debug Bar
Debug Bar er et sæt plugins, der er tilgængelige via en fejlretningsmenu på WordPress-administrationslinjen, som viser en bred vifte af fejlfindingsoplysninger. Dens muligheder inkluderer konsollen, kortkoder, konstanter, posttyper, cron, handlinger og filtre, transienter, fjernanmodninger og listescripts og stilafhængigheder. Det er et open source plugin, så det kan bruges gratis.
Hovedpluginnet, Debug Bar, giver basisfunktionaliteten, udvidet med resten af plugins. Det fungerer med de indbyggede fejlfindingsflag, der tilbydes af WordPress, såsom WP_DEBUG og SAVEQUERIES. Når disse flag er aktive, tilføjer Debug Bar nyttige debuggingsoplysninger, såsom PHP-advarsler og MySQL-forespørgsler, hvilket sparer dig for besværet med at lede efter og læse logfilerne.
Hver indstilling i menuen Fejlretningslinje giver sin andel af fejlfindingskraften. Konsollen giver for eksempel en konsol, hvor du kan køre vilkårlig PHP-kode, som er fremragende til at teste indholdet af variabler (blandt andet). Cron viser information om WordPresss planlagte begivenheder, såsom tidspunktet for næste begivenhed, antallet af planlagte begivenheder, listen over tilpassede planlagte begivenheder osv. Handlinger og filtre er en anden mulighed for at vise hooks knyttet til den aktuelle anmodning. Fanen Handlinger viser de handlinger, der er knyttet til den aktuelle anmodning, mens fanen Filtre viser alle filtertags sammen med de funktioner, der er knyttet til hver enkelt.
Fejlretning for alle
Debugging-værktøjer er for det meste designet til softwareudviklingsprofessionelle. Men selvom du ikke er en udvikler, hvis du bare vedligeholder en WordPress-blog, er det nyttigt at have mindst en grundlæggende viden om, hvordan du overvåger og fejlretter dit websted. Ved at gøre det kan du give en udvikler nogle oplysninger, der vil hjælpe ham eller hende med at finde kilden til et problem, på samme måde, at hvis du har det dårligt, kan du spare din læge for noget arbejde ved selv at tage din temperatur. inden man går på hospitalet.
Lær nogle måder at tjene penge på som WordPress-professionel.