Installera Xdebug, del 1: Xdebug-modulen

Senaste uppdateringen dec 7, 2022

Innehåll

Installera Xdebug, del 1

1 Felsökningsterminologi

Vid det här laget har vi täckt mycket mark när det gäller att arbeta med WordPress och felsökning. Och detta gäller särskilt när det gäller att arbeta med verktyg och plugins som är tillgängliga i WordPress. Om du bara går med i den här serien, se till att du har kommit ikapp med följande inlägg:

I förra inlägget, kom ihåg att jag sa följande:

Men om du vill komma in i en värld av professionell, praktisk felsökning från din IDE, då är det viktigt att förstå vad, hur och varför.

Och vi är äntligen redo att titta på vad detta kräver. För att komma igång betyder det dock att vi måste förstå några saker om Xdebug, terminologin, och att ha en IDE som är konsekvent för alla som läser just den här serien.

Så det här kommer att delas upp i två delar.

Först ska vi titta på terminologin som krävs för felsökning och se till att vi har en korrekt IDE-inställning i vår utvecklingsmiljö,
Därefter ska vi titta på hur vi kan säkerställa att vi har installerat Xdebug korrekt och sedan koppla upp det till vår utvecklingsmiljö så att vi kan få det att fungera.

Om du har läst en mängd olika innehåll i den här bloggen under de senaste åren kan en del av detta verka bekant. Om inte, ingen stor sak. Kom ihåg att målet är att se till att vi alla är på samma nivå när vi fortsätter med arbetet som nämns ovan och under resten av serien.

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

Installera Xdebug, del 1

Som nämnts ovan kommer denna uppsättning inlägg att tjäna ett av två syften som båda kan beskrivas kortfattat (det andra kommer att beskrivas i nästa inlägg):

Felsökningsterminologi
Installera en IDE

Även om många som läser detta redan kommer att känna till en del av terminologin (särskilt om du har använt verktyg på klientsidan eller till och med verktyg på serversidan tidigare), och du redan har en valfri redaktör, är det viktigt att se till att vi är åtminstone arbeta med en konsekvent grund.

Om du är säker på dina färdigheter över de två punkterna som nämns ovan, kommer nästa inlägg troligen att vara mer intressant för dig. Om, å andra sidan, det här börjar komma in på ett nytt territorium för dig bör det lägga grunden för allt du behöver för att se till att du lyckas felsöka projekt i WordPress.

Dessutom kommer det att se till att du har en konsekvent uppsättning verktyg att arbeta med så att vi kan fortsätta att driva framåt med en standarduppsättning verktyg för att skapa en så produktiv utvecklingsmiljö som möjligt.

1 Felsökningsterminologi

Beroende på din bakgrund kan du hävda att det finns någonstans mellan fem och sju termer som var och en är relaterade till felsökning. Jag har beskrivit det tidigare i andra inlägg på den här webbplatsen. Varje gång har jag dock gjort det med lite olika syn på innehållet.

I det här inlägget siktar jag på att försöka göra detta så exakt och exakt som möjligt så att det ger en konsekvent referens som vi kommer att kunna använda i inläggen (och i arbetet) som kommer. Som det ser ut nu, här är termerna som jag tycker att alla borde känna till när det gäller deras debugger.

Brytpunkter. Dessa kan betraktas som de grundläggande blocken för felsökning. Enkelt uttryckt är de platser i koden som du vill pausa körningen så att du kan undersöka vad som händer i koden. Kanske har detta att göra med variabler; kanske har det med funktioner att göra, kanske har det med något annat att göra. Oavsett vilket är detta viktigt eftersom du säger till programmet "hej, jag vill stoppa programmet från att köras här på den här raden så att jag kan undersöka programmets tillstånd."
Klockor. Dessa är funktionsanrop, variabler eller andra ställen i koden som kan ställas in så att vi bokstavligen kan se värden förändras under körningen. Om vi pratar om funktioner, kan vi hänvisa till värdena för argument som de ställs in och manipuleras i en funktion. Om vi pratar om variabler så pratar vi om variabler; då pratar vi om de värden de har vid varje given tidpunkt under programmets körning. Det kan vara när vi ställer in en specifik brytpunkt, eller så kan det vara när vi går igenom koden och håller ett öga på statusen för variabeln under programmets körning.
Starta. Denna åtgärd säger helt enkelt till felsökaren att börja övervaka webbservern. I grund och botten är det att hålla ett öga på allt som händer inom programmet och, om några brytpunkter ställs in, är det beredd att stoppa exekvering och tillåta oss att ta en titt på vad som händer med programmets tillstånd. Du kan tekniskt sett starta en felsökningssession och inte göra någonting alls. Det är inte direkt produktivt, men det är möjligt.
Gå in i. Antag för ett ögonblick att du har en brytpunkt inställd precis ovanför ett funktionsanrop eller på en funktionsanrop. Detta tillåter oss att gå in i funktionen för att övervaka värdet av varje argument, hur de manipuleras i funktionen, vad funktionen returnerar (om något) och allt som händer i funktionen.
Steg över. Å andra sidan, anta att du går igenom funktionen och att du inte är säker på att du vill dyka in i funktionen. Du kanske bara är intresserad av de värden som funktionen returnerar eller programmets tillstånd efter att funktionen har körts, men du är inte intresserad av vad som har hänt i funktionen. I huvudsak behandlar du det som en svart låda. Det är vad det innebär att gå över en funktion. Det vill säga att du låter funktionen köra utan att kliva in i den för att se den fungera.
Kliv ut. Den här speciella aspekten av felsökning är användbar när du befinner dig i en funktion och du är redo att återgå till huvudlinjen för exekvering eftersom du har sett allt du behöver se. Du kanske har sett att värdena för en variabel förändras, kanske har du sett en algoritm göra tillräckligt mycket arbete för att veta att den har gjort som du vill. Oavsett vilket kommer detta att tillåta dig att gå ut ur funktionen, det passande namnet, och sedan flytta in i
Sluta. Precis som start säger åt felsökaren att börja lyssna på servern, vara uppmärksam på brytpunkter och visa information om programmets framsteg, gör stop precis tvärtom. Den talar om för felsökaren att vi är klara med att lyssna, titta på och uppmärksamma programmets tillstånd. Det betyder inte att programmet stannar – bara felsökaren. Så om du är klar med att vara uppmärksam på all information som tillhandahålls av felsökaren, är du troligen i stånd att stoppa felsökaren.

En sista anmärkning jag skulle vilja göra är att PHP är unikt genom att det erbjuder en mängd olika offentligt tillgängliga variabler som $_GET , $_POST, $_REQUEST, och så vidare. Detta är också variabler som är tillgängliga för oss som vi kan titta på. Det är inte bara begränsat till vad vi har skrivit i vår kod.

Detta är särskilt användbart eftersom vi tittar på data över sidåterladdningar, Ajax-förfrågningar (som under GET- och POST-åtgärder) och så vidare.

2 Installera Xdebug

Även om det troligen är uppenbart från tidigare inlägg i den här serien, kommer jag att använda Visual Studio Code som mitt val av IDE. Om du inte har en så är den här en jag rekommenderar. Om du däremot har en IDE som du är bekväm med att använda så är detta en som jag rekommenderar.

Koden är alltid under utveckling,
har en aktiv förlängningsekonomi,
fungerar bra med en mängd olika språk, verktyg och så vidare,
är lätt och spelar bra med de olika sakerna vi kan användas i WordPress-utveckling (som PHP, HTML och JavaScript).

Dessutom har Code också ett bra stöd för Xdebug. För att säkerställa att felsökaren är korrekt installerad måste vi dock se till att vi har tillägget installerat med vår installation av PHP, att det är tillgängligt i hela vårt system och att det kan köras i vår IDE. Vi kommer att titta på att göra detta, men först måste vi se till att Xdebug är korrekt installerat.

Installerar Xdebug

Det är enkelt att installera Xdebug. Inifrån din terminalsession måste du utföra följande kommando:

När du gör det kommer du att märka flera saker som händer i terminalfönstret när installationen äger rum. Om du inte är särskilt intresserad behöver du inte oroa dig för vad den gör förrän den återgår till kommandotolken.

Vid det här laget har Xdebug-modulen installerats; men du kommer att behöva berätta för PHP att den är installerad och var den kan hitta modulen.

För att installera tillägget med din nuvarande version av PHP är det viktigt att veta vilken version av PHP du har installerat. Om du använder en pakethanterare, så finns det kanske flera versioner och du kommer att behöva berätta för den specifika versionens konfigurationsfil var du kan hitta modulen.

Omvänt, om du har en enda version installerad, måste du berätta för en enda version av PHP var den är installerad. Först kan du hitta var Xdebug finns i filsystemet med detta kommando:

Då kommer du att behöva uppdatera konfigurationsfilen för din PHP-installation. För att göra detta, kör helt enkelt php -v från kommandoraden och den kommer att berätta vilken version du kör. Härifrån kommer du att behöva hitta initieringsfilen för den version av PHP som du använder. Om du, när du kör php -v, kommer tillbaka med något i stil med detta:

Detta talar om för oss att vi kör PHP 7.1.19 (även om din version kan variera). Härifrån vet vi att vi ska leta efter en viss PHP-konfigurationsfil för den här versionen av PHP. För att göra detta, leta efter php.ini i katalogen /usr/local/etc/php/7.1/ på ditt system (även om det exakta versionsnumret kan variera).

Öppna filen därifrån och lägg sedan till följande kodrad:


zend_extension="/usr/local/lib/php/pecl/20160303/xdebug.so"

Detta kommer att berätta för PHP var Xdebug finns så att den kan användas i ditt arbete.

Testa installationen

För att verifiera att installationen har gått korrekt kan du köra följande kod i din terminal:

Och då bör du se något i stil med följande utdata på skärmen:

Observera att i skärmdumpen ovan ser du följande:

med Xdebug v2.6.0, Copyright (c) 2002-2018, av Derick Rethans

Det betyder att modulen har installerats och att PHP är medveten om det.

Konfigurera din IDE

I nästa inlägg kommer vi att titta på att knyta Xdebug till vår IDE. Förutsatt att du har följt stegen i det här inlägget och att allt har gått bra, bör du vara bra att gå när det gäller förberedelser för att felsöka WordPress-projekt.

Tills vi har det igång inom en IDE är det dock inte lika användbart (eller svårare än det måste vara). Så nästa vecka ska vi titta på exakt hur man gör det.

Inspelningskälla: tommcfarlin.com