Hur Xdebug kan hjälpa dig att bli en bättre WordPress-utvecklare

Som alla utvecklare kan intyga är kod aldrig redo för produktion efter det första utkastet. En viktig del av utvecklingsprocessen är felsökning — att ta bort eller ändra alla delar av koden som inte fungerar.

Tillägget Xdebug för PHP är ett populärt sätt att hitta åt och förstöra alla fel i din kod.

En av de fantastiska aspekterna av Xdebug är hur flexibelt det är. Oavsett vilket ramverk eller vilken utvecklingsmiljö som du föredrar så kommer du att kunna hitta en version av Xdebug som passar in i ditt arbetsflöde. Sen tar det inte lång tid att få grepp om verktyget.

Den här handledningen kommer att titta på Xdebug på djupet, inklusive installationsprocess, integrering i din installation och allmän användning.

Men låt oss först ge dig lite mer sammanhang om vad Xdebug är och vad det gör.

Presentation av Xdebug

Xdebug är ett av de mest populära tilläggen för att felsöka din PHP-kod. Du installerar det från din valda miljö och det fungerar som en ”stegvis felsökare”

Kort sagt gör detta att du kan arbeta med din kod rad för rad så att du kan gå igenom och titta på hur koden agerar och interagerar i ditt program, samt undersöka dess utdata. Därifrån kan du göra de ändringar som du anser vara lämpliga.

Xdebug kan dock göra mycket mer:

• Du kan analysera prestandan hos din kod med hjälp av en uppsättning mätvärden och visualiseringar.
• När du kör PHP-enhetstester så kan du se vilka kodsviter som körs och exekveras.
• Xdebug innehåller ”spårnings”-funktioner som skriver varje funktionsanrop till disken. Detta kommer att inkludera argument, variabeltilldelningar och returvärden.
• Xdebug gör även förbättringar av PHP:s standardfelrapportering. Vi kommer att ta upp mer om detta senare.

Med tanke på funktionerna så finns det många sätt att använda Xdebug (och andra liknande felsökare) i ditt arbetsflöde. Vi tar upp dessa i nästa avsnitt.

Varför du bör använda Xdebug

Många utvecklare kommer inte att ha ett dedikerat arbetsflöde för felsökning som använder verktyg och tillägg från tredje part. Detta beror på att PHP inkluderar sin egen rudimentära felloggning. Du kommer att använda kommandon som error_log, var_dump och print för att se resultaten av variabler och funktionsanrop.

Det finns exempelvis massor av utdrag som du kan återanvända för WordPress-utveckling — Stack Overflow är fullt av dem:

function log_me($message) {
  if ( WP_DEBUG === true ) {
      if ( is_array($message) || is_object($message) ) {
          error_log( print_r($message, true) );
      } else {
           error_log( $message );
      }
  }
}

Det finns dock några viktiga nackdelar med detta tillvägagångssätt:

• Du måste först se till att du aktiverar felrapportering för den plattform som du arbetar med. I det här fallet bör du aktivera WP_DEBUG (mer om detta strax).
• Det här exemplet om ”dump”-felsökning ger mindre utrymme för undersökning än stegvis felsökning. Här kan du bara ge ut det som du definierar.

Den sistnämnda punkten kräver mycket manuellt arbete, särskilt om du inte arbetar som systemadministratör. Om du exempelvis vill felsöka ett kodblock så kan du lägga till ditt utdrag baserat på en variabel som du definierar. Den kanske dock inte är källan till problemet eller ens indikerar vad som händer.

Istället kan ett verktyg som Xdebug utföra sin magi för att skapa en större räckvidd:

• Du kan ”bryta” din kod vid olika punkter under utförandet för att se vad som händer i realtid.
• Det finns otaliga mätvärden, visualiseringar, grenar med mera som hjälper dig att ta reda på vad din kod gör och hur den reagerar.
• Ibland kan du till och med ändra värden i farten under felsökningsprocessen. Detta erbjuder ett enormt värde, även för sviter av kod som fungerar bra. Du kan i princip utföra manuella enhetstester när som helst.
• Eftersom du använder brytpunkter för att markera felsöknings-områden så behöver du inte arbeta med utdrag i din kod. Detta håller din kod renare och minskar antalet framtida problem.

På det hela taget är användningen av ett verktyg som Xdebug ett proaktivt beslut snarare än ett reaktivt. Du kan använda stegvis felsökning som en del av den centrala utvecklingsprocessen, ungefär som implementering av enhetstester som en del av testdriven utveckling (TDD).

Så här aktiverar du PHP-felloggning

Även om du kan felsöka din kod utan ett specifikt fel så är det ofta bra att veta om ett problem uppstår utan att Xdebug är öppet. Detta ger dig en utgångspunkt för utforskning. Det är inte strikt nödvändigt, men kan vara en nyttig del av din kedja.

För att rapportera varje fel som uppstår så måste du lägga till en rad högst upp i den relevanta PHP-filen:

error_reporting(E_ALL);

Detta är ett kommando för att fånga upp alla, och du kan uppnå samma sak med hjälp av ini_set -funktionen:

ini_set('error_reporting', E_ALL);

Detta gör att du kan ändra inställningar i din php.ini-fil projekt för projekt. Även om du kan gå in i filen och göra en manuell ändring så är det ofta en bättre idé att arbeta med ini_set för att ändra den specifika parametern:

ini_set('display_errors', '1');

När du har ställt in aktiv felrapportering enligt dina önskemål så kan du börja arbeta med Xdebug.

Hur man använder Xdebug

Under de kommande avsnitten kommer vi att visa dig hur du använder Xdebug, inklusive de steg som du behöver ta för att ställa in saker och ting. Även om vi inte kan gå igenom alla verktygsaspekter så kommer den här snabbstartguiden att få dig att komma igång snabbt.

Först måste du dock installera Xdebug. Låt oss ta reda på hur du gör detta.

1. Installera Xdebug för ditt operativsystem (OS)

Eftersom Xdebug kan anpassas till ett oändligt antal konfigurationer så kommer den exakta processen för varje system att vara något annorlunda. Det finns även några skillnader på OS-nivå:

• Windows: Detta är en något komplicerad installationsprocess som innebär att du använder en befintlig PHP-fil och en installationsguide och sedan laddar ner rätt version för ditt system.
• Linux: Metoden här är utan tvekan den mest okomplicerade: Du kan använda en pakethanterare för att installera Xdebug eller PHP Extension Community Library (PECL).
• Mac: Den här metoden är också enkel: När du har installerat PECL så kan du köra pecl install xdebug från en Terminal-instans. Du måste även ha kommandoradsverktyget XCode och PHP installerat på ditt system.

De flesta användare bör dock inte hålla sig till en instans av Xdebug på systemnivå. Istället bör du integrera den i din egen utvecklingsmiljö.

2. Integrera Xdebug i din utvecklingsmiljö

När du har installerat Xdebug för ditt operativsystem bör du ansluta det till din miljö.

Det finns så många system och verktyg som stöds här att vi inte kan gå in på alla. Vi kommer senare att erbjuda dig instruktioner för både DevKinsta och PhpStorm. Trots detta så finns det många andra populära miljöer att välja mellan. Nedan följer några av våra främsta rekommendationer.

Varying Vagrant Vagrants (VVV)

VVV är en av de namngivna miljöerna på webbplatsen Make WordPress:

Den goda nyheten är att VVV redan innehåller en version av Xdebug, men du måste aktivera den. Du kan göra detta med hjälp av Secure Shell (SSH) i ett terminalfönster:

vagrant ssh -c "switch_php_debugmod xdebug"

Det kan dock skapa en prestandasvacka, och du måste aktivera det här alternativet igen om du felsöker dina webbplatser.

Laravel Valet

För vissa användare representerar Laravels Valet en nästan perfekt webbutvecklingsmiljö. En sak som är ännu bättre är att du kan integrera Xdebug med den.

För att göra detta måste du skapa en konfigurationsfil för felsökaren. Du kan hitta din egen sökväg med hjälp av php --ini på kommandoraden, vilket ger dig några olika filsökvägar:

Skapa sedan en ny xdebug.ini-fil i sökvägen för ytterligare .ini-filer. I vårt exempel ligger den på /opt/homebrew/etc/php/7.4/conf.d.

När du öppnar den nya filen så öppnar du även sökvägen till den laddade konfigurationsfilen (din huvudsakliga php.ini-fil). När båda är öppna lägger du till följande längst ner:

• php.ini: zend_extension="xdebug.so"
• xdebug.ini: xdebug.mode=debug

När du har sparat ändringarna kör du valet restart från terminalen och lägger sedan till phpinfo(); exit; i en av webbplatsens filer. Du bör kontrollera om detta fungerar genom en snabb sidladdning i webbläsaren.

Observera att du kan behöva starta om PHP med hjälp av sudo brew services restart php samt kontrollera att din systeminstallation av Xdebug är korrekt med hjälp av php --info | grep xdebug. Du kommer att lägga märke till de Xdebug-specifika raderna i utdatan:

Härifrån kan du leta efter att införliva Xdebug i din valfria kodredigerare.

XAMPP

I likhet med Valet så finns det några delar i processen för XAMPP. Windows- och macOS-versionerna har dock två olika processer.

Börja med att installera XAMPP och gör sedan en snabb kontroll för att se om filen php_xdebug.dll (Windows) eller xdebug.so (macOS) finns på ditt system:

Om filen finns så kan du gå vidare till konfigurationen. Annars måste du först ladda ner antingen rätt binärfil för Windows — en 64-bitarsfil för din föredragna PHP-version — eller installera några fler beroenden om du använder Mac.

För Windows byter du namn på DLL-filen php_xdebug.dll och flyttar den sedan till \xampp\php\ext-filsökvägen. Öppna sedan filen \xampp\php\php.ini i din föredragna kodredigerare och lägg till följande:

output_buffering = Off

I sektionen [XDebug] lägger du till följande tre rader:

zend_extension=xdebug
xdebug.mode=debug
xdebug.start_with_request=trigger

När du har sparat ändringarna så startar du om Apache och testar Xdebug.

För Mac bör du se till att du installerar Xcode-kommandoradsverktygen med hjälp av xcode-select --install i en Terminal-instans. Därefter finns det tre paket som du bör installera med hjälp av Homebrew:

brew install autoconf automake libtool

I vissa fall måste du även installera om XAMPP för att både få kärnprogrammet och ”Developer Files” Du bör kunna ominstallera endast dessa filer, men du bör först göra en säkerhetskopia av din befintliga installation.

Navigera sedan till nedladdningen för Xdebug-källmappen på ditt system och packa upp TGZ-filen. I ett Terminal-fönster navigerar du till den katalogen och kör följande:

phpize
pecl install xdebug

Observera att du kan behöva använda sudo även här. Härifrån kan du redigera XAMPP:s php.ini-fil. För de flesta macOS-installationer hittar du den i /Applications/XAMPP/xamppfiles/etc/php.ini. I den här katalogen hittar du även sökvägen till din xdebug.so-fil — notera den och använd den i stället för filvägsplaceringshållaren i det här avsnittet:

[xdebug]
zend_extension=/path/to/xdebug.so
xdebug.mode=develop,degug
xdebug.start_with_request=yes

För att testa om detta fungerar så skapar du en ny fil xdebug_info.php i huvudkatalogen htdocs XAMPP. Där lägger du till följande:

<?php
xdebug_info();

…uppdatera sedan Apache och testa Xdebug i webbläsaren.

Använda PhpStorm med Xdebug

När du har installerat Xdebug via operativsystemet och din utvecklingsmiljö så måste du även visa själva felsökaren. Du gör detta genom din valda kodredigerare eller integrerade utvecklingsmiljö (IDE). Precis som med din miljö så finns det så många att välja mellan, och alla kan ha olika tillvägagångssätt.

Med detta sagt väljer många utvecklare att använda JetBrains PhpStorm. PhpStorm erbjuder faktiskt ”WordPress-aware assistance” — och det är ett populärt val även av många andra skäl.

På JetBrains webbplats finns fullständiga instruktioner om hur man ansluter Xdebug och PhpStorm, men vi går igenom dem här.

Navigera först till sidan Språk & Ramverk > PHP i fönstret Inställningar. Här öppnar du kebabmenyn Mer objekt bredvid rullgardinsfältet CLI Tolken:

Här visas ytterligare information om din PHP-version och tolk. Om du klickar på ellipsen Fler objekt bredvid alternativet Konfigurationsfil visas fullständiga sökvägar för din php.ini-fil:

Du kommer härnäst att arbeta med den här PHP-filen för att fortsätta installationsprocessen.

Arbeta i filen php.ini

Den första uppgiften här är att redigera alla rader som påverkar hur Xdebug kommer att fungera med PhpStorm.

I filen php.ini letar du efter följande rader och tar antingen bort dem eller kommenterar dem:

zend_extension=<path_to_zend_debugger>
zend_extension=<path_to_zend_optimizer>

Dessa rader kommer inte att finnas i alla fall, så bli inte orolig om du inte ser dem.

Lägg sedan till följande i filen:

[xdebug]
zend_extension="xdebug.so"
xdebug.mode=debug
xdebug.client_host=127.0.0.1
xdebug.client_port="<the port (9003 by default) to which Xdebug connects>"

Det finns några saker att notera om den här kodsviten:

• Du kanske redan har en sektion för [xdebug], i så fall kan du utelämna den första beteckningen.
• I sektionen zend_extension så kan du behöva lägga till den fullständiga sökvägen till xdebug.so för att ansluta.
• Även om det kan se ut som en platscontainer, är parametern xdebug.client_port hur du kommer att ställa in den i din kod.

När du har lagt till dessa, spara och stäng filen och testa sedan PHP-versionen från kommandoraden (med hjälp av php --version):

Om du har en fungerande version av Xdebug så kommer den att visas som ett av PHP-tilläggen. Du kan även lägga till phpinfo(); i en ny fil och testa detta i webbläsaren.

Detta är i stort sett allt som du behöver göra för att få Xdebug att fungera som din standard-felsökare med PhpStorm. Det sista steget innan du använder det är att installera ett webbläsartillägg som hjälper dig.

Installera ett webbläsartillägg

Den sista nyckelkopplingen som du behöver göra är mellan din webbläsare och PhpStorm, vilket åstadkoms genom aktivering av stegvis felsökning på servern. Även om du kan göra detta från kommandoraden med hjälp av speciella värden GET eller POST så är det enklare att använda ett tillägg.

Vi rekommenderar att du använder det dedikerade tillägget Xdebug Helper. Du kan installera detta i valfri webbläsare:

• Xdebug Helper för Chrome/Chromium/Brave
• Xdebug Helper för Firefox

Om du vill utforska andra tillägg så erbjuder JetBrains webbplats några ytterligare alternativ för de mest populära webbläsarna.

När du har installerat ditt valda webbläsartillägg så bör du inte behöva justera några ytterligare konfigurationsinställningar. Härifrån kan du börja använda Xdebug med PhpStorm.

Användning av Xdebug

Även om vi kommer att använda PhpStorm här så kommer du att se en liknande layout och liknande gränssnitt mellan olika IDE:er — även om det även kommer att finnas några uppenbara skillnader.

Det finns några begrepp som tillsammans bildar hela felsökningsupplevelsen:

• Brytpunkter: Detta är de punkter där Xdebug stannar till för att låta dig inspektera utdata. Du kan ställa in så många av dessa som du vill.
• Lyssning på anslutningar: Du kan växla den här funktionen till och från, även om de flesta utvecklare alltid låter den vara på.
• Skärmen för felsökning:

  Större delen av din tid kommer att spenderas i felsökningsgränssnittet — Det är här som du arbetar med de olika kodraderna, variablerna och parametrarna.

Det första steget är att aktivera lyssning — du kommer inte att kunna felsöka något utan detta. För att göra detta klickar du på alternativet Kör > Börja lyssna efter PHP Felsöknings-anslutningar i verktygsfältet:

Som ett alternativ kan du klicka på ikonen ”telefon” i PhpStorms verktygsfält:

Något av dessa alternativ kommer att starta lyssnandet efter anslutningar.

Härifrån kan du börja ställa in brytpunkter i kodredigerarens rännor. En röd prick visar en brytpunkt som du kan klicka på för aktivering:

När du vill felsöka din kod så är det enklaste sättet att börja lyssna, ställa in brytpunkter och sedan gå till den specifika sidan i webbläsaren. Leta upp ikonen för ditt tillägg i webbläsaren, klicka sedan på den och välj alternativet ”Felsök”:

Detta kommer att öppna felsökaren i PhpStorm och antingen leverera goda eller dåliga nyheter:

Om du högerklickar på de olika värdena, attributen, parametrarna och variablerna så får du tillgång till ytterligare en kontextmeny. Detta ger dig många extra möjligheter att testa och felsöka din kod:

Du kan exempelvis ställa in olika värden för variabler längs vägen. Detta kan vara ett medvetet försök att bryta din kod och se vad som händer, eller så kan det vara ett sätt att testa kod som redan behöver en korrigering. Oavsett vilket så ger detta dig en fantastisk metod för att felsöka din kod utan att du behöver ändra den först.

Hur Kinsta hjälper dig att felsöka din WordPress-webbplats

WordPress har sina egna felsökningsalternativ via WP_DEBUG och andra verktyg, exempelvis Query Monitor. Dessa möjliggör ett läge där du börjar se tidigare dolda felmeddelanden över hela din webbplats och instrumentpanel. Därifrån kan du börja ta reda på vad problemet är.

Du kan även spara dessa felmeddelanden med hjälp av WP_DEBUG_LOG, vilket ger dig ett sätt att dokumentera problemen på din webbplats. Vi tar upp hur du ställer in detta i en annan artikel på bloggen. Detta är enkelt att ställa in via din MyKinsta-instrumentpanel (och skärmen Webbplatser > Verktyg):

Om du kombinerar detta med det kostnadsfria DevKinsta-verktyget för lokala miljöer så har du även ett sätt att med ett enda klick aktivera och inaktivera WP_DEBUG för varje webbplats som du startar:

Detta innebär att du kan fånga upp fel på din webbplats under utvecklingen och se till att de inte når fram till din livesida. Dessa lägen är även lätta att stänga av — viktigt för både webbplatsens och användarens säkerhet.

Alla Kinsta-planer levereras även med det inbyggda Kinsta APM-verktyget, som är vårt specialutformade verktyg för prestandaövervakning för WordPress-webbplatser.

Kommando fusklappar

Innan vi avslutar det här inlägget så bör vi nämna genvägar.

Precis som hos många andra programvaror så finns det olika sätt att navigera runt i Xdebug (och PhpStorm) enbart med hjälp av tangentbordet. Du kan till och med använda kommandoraden för att felsöka PHP-skript.

När Xdebug väl är igång så kan du använda följande kommandon för att ta dig runt:

Även om din specifika kodredigerare kommer att ha sina egna dedikerade genvägar så är fokus här på PhpStorm. Ta en titt på den här tabellen med tangentbordsgenvägar för att använda Xdebug med PhpStorm:

Det finns tack och lov inte mycket att memorera här. Du måste öppna felsökaren, ställa in brytpunkter per rad, lyssna på anslutningar och köra dina skript.

Men om du behöver en genväg för en viss uppgift så kan du använda kommandot PhpStorm Hitta Åtgärd:

När du börjar skriva i det här utrymmet så visas en dynamisk lista över kommandon och tillhörande genvägar. Du kan även hitta en PDF-version av alla tangentbordsgenvägar via menyn Hjälp > Tangentbordsgenvägar PDF.

Om du vill ha mer av en realtidsutsikt över genvägar när du arbetar med musen tillhandahåller JetBrains pluginet Key Promoter X:

Det här praktiska verktyget visar meddelanden om din senast utförda åtgärd, tillsammans med dess relaterade tangentbordsgenväg. När du väl har lärt dig och använder genvägarna så kan du fasa ut detta plugin och återställa värdefull yta på din skärm.

Sammanfattning

Felsökning har kommit långt från sin blygsamma början och omfattar nu ett mycket större tillämpningsområde än vad dess föregångare kunde ha föreställt sig. För att utföra ett grundligt arbete när det gäller att fixa till din PHP-kod så måste du dock använda ett kompetent verktyg. Det finns många utmärkta tillägg och verktyg att välja mellan, men Xdebug är en rekommendation.

Som vi har sett så kan Xdebug anpassa sig till de flesta kodredigerare, och det är särskilt bra när det paras ihop med PhpStorm. Oavsett vilken inställning som du har så finns det dock ofta en version av Xdebug som passar bättre för just dina behov. På det hela taget är det ett kraftfullt, flexibelt och intuitivt verktyg.

Tycker du att Xdebug förtjänar sitt stora beröm, eller finns det ett annat felsökningsverktyg som du föredrar? Låt oss veta i kommentarsfältet nedan!