Inbyggda WordPress-felsökningsverktyg som inte kräver en IDE

Senaste uppdateringen dec 3, 2022

Innehåll

Om du just har råkat bli medlem på webbplatsen och söker innehåll specifikt för The Independent WordPress Developer rekommenderar jag att du läser det föregående inlägget – åtminstone – för att förbereda dig för innehållet i det här inlägget.

Om du däremot vill komma ikapp den tidigare artikeln, här är en kort lista över allt som har skrivits hittills:

När vi förbereder oss för att gå vidare till att prata om mer avancerade ämnen som felsökning och IDE är det först värt att notera de verktyg vi har tillgängliga verktyg som vi kan installera i WordPress som hjälper oss med felsökningsproblem under utvecklingen.

Vidare är dessa problem inte relaterade till strikt PHP-frågor. Dessa inkluderar även JavaScript-problem. Och för att ta det ett steg längre, det finns sätt på vilka vi kan konfigurera WordPress inbyggt så att det matar ut fel direkt till vår webbläsare.

Så innan vi tittar på felloggar, IDE, Xdebug och så vidare, ska vi ta en titt på vad vi kan göra inom själva WordPress.

Inbyggda WordPress-felsökningsverktyg

De inbyggda WordPress-felsökningsverktygen är en kombination av två saker:

alternativen vi kan ställa in i WordPress-konfigurationsfilen som tillåter oss att se information skriven på skärmen,
flera plugins som hjälper oss att arbeta med PHP- och JavaScript-filer från WordPress-administrationsområdet

För den andra punkten ovan vill jag vara tydlig med att det finns många tillgängliga plugins för något sådant här; Jag vill dock hålla installationen så smidig som möjligt så att vi inte översvämmas av för mycket information.

Istället vill jag att vi ska ha den information vi behöver för att testa och utvärdera vårt arbete men att vi bara har det vi behöver. Åtminstone för stunden. Kanske kommer vi att prata om avancerade ämnen i framtida inlägg.

Med det sagt, låt oss börja.

WordPress-konfiguration

Innan du oroar dig för konfigurationen ger WordPress i sig några olika alternativ som vi kan konfigurera i wp-config.phpfilen. Dessa är väldokumenterade i Codex, men jag vet av erfarenhet av e-postmeddelanden från andra att informationen kan vara lite svår att sålla igenom.

Först är det viktigt att notera följande (som citerats från WordPress Codex):

WP_DEBUG är en PHP-konstant (en permanent global variabel) som kan användas för att trigga "debug"-läget i hela WordPress. Det antas vara falskt som standard och är vanligtvis satt till sant i filen wp-config.php på utvecklingskopior av WordPress.

Detta förutsätter att du förstår PHP-konstanter. Om inte, kolla in manualen här (den är ganska enkel). Det korta av det är som följer:

En konstant är en identifierare (namn) för ett enkelt värde.

Så jag ska göra vad jag kan för att tillhandahålla konfigurationsalternativen så destillera det så mycket som möjligt.

Först i wp-config.phpfilen vill du ändra raden som lyder:

<?php
define( 'WP_DEBUG', false );

Till detta :

<?php
define( 'WP_DEBUG', true );

Det är dock inte allt. Det finns några fler saker att lägga till som kommer att förbättra felsökningsupplevelsen:

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );

Om du följer med i Men vad betyder varje rad? Här är en så kortfattad förklaring som jag kan ge just nu:

WP_DEBUG. Detta kommer att visa alla fel och varningar som skickas av PHP när du kör WordPress. Att köra programmet i sig bör inte visa några problem; Men att köra den tillsammans med olika plugins kan vara en annan historia beroende på kvaliteten på plugin.
WP_DEBUG_LOG. Detta är en av mina favoritkonstanter, och den skriver all utdata till loggen på ett detaljerat sätt. Jag kommer att täcka detta i ett kommande inlägg men, för nu, vet att det här är något som jag tycker alltid bör ställas in i din utvecklingsmiljö.
WP_DEBUG_DISPLAY. Detta är en som du kan ställa in på sant eller falskt (även om jag föredrar sant). Den kompletterar den tidigare inställningen genom att låta dig se meddelanden i webbläsaren som också skrivs till bloggen. Jag vet inte om detta är något som du kommer att tycka är fördelaktigt eller inte. Om du inte är beredd att gå igenom stackspår och mer detaljerad information, kanske du vill överväga att ställa in denna till sann.
dislay_errors. Codexen nämner att du kan ställa in detta lika med falskt, men jag tror att det bör ställas in på sant som ett sätt att aktivera felen och varningen.
SCRIPT_DEBUG. WordPress kärna använder minifierade versioner av CSS- och JavaScript-filer. Om du stänger av den här inställningen kan du se allt innehåll i filerna i originalformen. Detta är särskilt användbart om du ska bidra till Core eller arbeta med JavaScript som ingår i Core.
SPARAFRÅGOR. Det här är en lite mer avancerad inställning, enligt mig. Kort sagt, det kommer att ta alla frågor som körs mot databasen och spara dem i en PHP-array som du senare kan analysera. Det

Nu när vi har täckt WordPress-konfigurationen, hur är det med plugins?

Plugins för felsökning

När jag säger att förvaret är fullt av plugins för detta menar jag det. Faktum är att om du är ny på WordPress-utveckling, skulle jag inte rekommendera att leta efter saker att installera.

Det kan snabbt bli överväldigande, du riskerar att inte förstå vad vissa av dem gör och potentiellt leda dig ner på en väg där du hamnar i att borra din installation.

Istället för att göra det rekommenderar jag att du tar en titt på följande plugins (läser förstås deras beskrivning först) och går sedan därifrån:

Felsökningsfältet. Bara detta plugin lägger till en meny till adminfältet som låter dig se frågan, cachen och annan information. Det kräver att WP_DEBUG och SAVEQUERIES som beskrivs ovan är aktiverade.
Debug Bar List Script & Style beroenden. Detta är ett tillägg till ovanstående plugin som gör att du kan felsöka ytterligare JavaScript- och CSS-stilar som körs inom WordPress-sammanhang.
Debug Bar Console. Denna plugin är en som du bör använda med tvekan. Åtminstone låter det dig köra PHP och MySQL från själva WordPress. Jag rekommenderar inte detta plugin såvida du inte är mycket bekväm med något av de två språken. Ändå, om du är det, är detta något som kan vara kraftfullt för att prototypa en funktion eller en fråga innan du bygger in den i ditt plugin.

Undersöker felloggar

I nästa inlägg börjar vi titta på vad som är nödvändigt för att undersöka felloggen som genereras av WordPress och hur man förstår informationen vi ser.

Dessutom kommer vi att undersöka vad som är nödvändigt för att använda plugins som beskrivs i det här inlägget. Efter det går vi vidare till ännu mer avancerade verktyg.

Men ett steg i taget, eller hur?

Än så länge, konfigurera din installation enligt ovan, installera de länkade plugins och gör sedan vad du kan för att utforska hur de fungerar, vad du kan se på skärmen och hur detta kan påverka och positivt gynna din utveckling.

Ja, det kan finnas lite av en inlärningskurva. Men det är därför vi tar det så långsamt. Det finns mycket att lära, och vi har gott om tid för att täcka all mark som är nödvändig.

Inspelningskälla: tommcfarlin.com