Som enhver udvikler kan bekræfte, er kode aldrig klar til produktion efter det første udkast. En vigtig del af udviklingsprocessen er fejlfinding — at fjerne eller ændre de dele af din kode, der ikke virker.
Xdebug-udvidelsen til PHP er en populær måde at finde og reparere alle fejl i din kode på.
Et af de gode aspekter ved Xdebug er, hvor fleksibelt det er. Uanset hvilket framework eller udviklingsmiljø du foretrækker, vil du kunne finde en version af Xdebug, der passer ind i din arbejdsgang. Derfra vil det ikke tage lang tid at få styr på værktøjet.
Denne vejledning vil se nærmere på Xdebug, herunder installationsprocessen, integration af det i din opsætning og generel brug.
Lad os først give dig mere kontekst om, hvad Xdebug er, og hvad det gør.
Introduktion af Xdebug
Xdebug er en af de mest populære udvidelser til at debugge din PHP-kode. Du installerer det fra dit valgte miljø, og det fungerer som en “step debugger”
Kort sagt gør det dig i stand til at arbejde på din kode linje for linje, så du kan gå igennem og se på, hvordan koden virker og interagerer i dit program, samt undersøge dets output. Derfra kan du foretage de ændringer, som du finder passende.
Xdebug kan dog gøre meget mere:
- Du kan analysere ydeevnen af din kode ved hjælp af en række målinger og visualiseringer.
- Når du kører PHP-enhedstests, kan du se, hvilke kodesuiter du kører og udfører.
- Xdebug indeholder “tracing”-funktioner, som skriver hvert funktionskald til disken. Dette vil omfatte argumenter, variabeltildelinger og returværdier.
- Xdebug foretager også forbedringer af standard PHP-fejlrapporteringen. Vi vil dække mere om dette senere.
I betragtning af funktionerne er der masser af måder at bruge Xdebug (og enhver lignende debugger) i din arbejdsgang på. Vi vil dække disse i næste afsnit.
Hvorfor du ønsker at bruge Xdebug
Mange udviklere vil ikke have en dedikeret debugging-arbejdsgang, der bruger tredjepartsværktøjer og udvidelser. Dette skyldes, at PHP indeholder sin egen rudimentære fejllogning. Du bruger kommandoer som error_log
, var_dump
og print for at se resultaterne af variabler og funktionskald.
Der er f.eks. masser af snippets, som du kan genbruge til WordPress-udvikling — Stack Overflow er fyldt med 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 );
}
}
}
Der er dog nogle vigtige ulemper ved denne fremgangsmåde:
- Du skal først sikre dig, at du aktiverer fejlprotokoller for den platform, du arbejder med. I dette tilfælde skal du aktivere
WP_DEBUG
(mere om dette om lidt). - Dette eksempel på “dump”-fejlfinding giver mindre mulighed for undersøgelse end step-fejlfinding. Her kan du kun outputte det, du definerer.
Sidstnævnte punkt kræver en stor manuel indsats, især hvis du ikke arbejder som systemadministrator i dit daglige arbejde. Hvis du f.eks. ønsker at debugge (fejlfinde) en kodeblok, kan du tilføje dit uddrag baseret på en variabel, du definerer. Det er dog ikke nødvendigvis kilden til problemet eller indikerer endda, hvad der sker.
I stedet kan et værktøj som Xdebug udføre sin magi for at give et større omfang:
- Du kan “bryde” din kode på forskellige punkter under udførelsen for at se, hvad der sker i realtid.
- Der findes et utal af målinger, visualiseringer, branches og meget mere, der kan hjælpe dig med at fastslå, hvad din kode gør, og hvordan den reagerer.
- Nogle gange kan du endda ændre værdier i farten under debuggingprocessen. Dette giver en enorm værdi, selv for kodesæt, der fungerer godt. Du kan i det væsentlige udføre manuelle enhedstests på et hvilket som helst tidspunkt.
- Fordi du bruger breakpoints til at markere områder, der skal debugges, behøver du ikke at arbejde med snippets i din kode. Dette holder din kode renere og reducerer antallet af fremtidige problemer.
Alt i alt er det at bruge et værktøj som Xdebug en proaktiv beslutning snarere end en reaktiv beslutning. Du kan bruge step debugging som en del af den centrale udviklingsproces, ligesom du kan implementere enhedstests som en del af testdreven udvikling (TDD).
Sådan slår du PHP-fejllogning til
Selvom du kan debugge din kode uden en specifik fejl, er det ofte godt at vide, om et problem opstår uden at have Xdebug åben. Dette giver dig et udgangspunkt for udforskning. Det er ikke strengt nødvendigt, men kan være en nyttig del af din kæde.
Hvis du vil rapportere hver eneste fejl, der opstår, skal du tilføje en linje øverst i den relevante PHP-fil:
error_reporting(E_ALL);
Dette er en catch-all kommando, og du kan opnå det samme ved at bruge ini_set
funktion:
ini_set('error_reporting', E_ALL);
Dette giver dig mulighed for at ændre indstillingerne i din php.ini-fil på projektbasis. Selvom du kan gå ind i denne fil og foretage en manuel ændring, er det ofte en bedre idé at arbejde med ini_set
for at ændre den specifikke parameter:
ini_set('display_errors', '1');
Når du har indstillet aktiv fejlrapportering efter din smag, kan du begynde at arbejde med Xdebug.
Sådan bruger du Xdebug
I løbet af de næste par afsnit vil vi vise dig, hvordan du bruger Xdebug, herunder de trin, du skal bruge for at sætte tingene op. Selv om vi ikke kan dække alle værktøjsaspekter, vil denne quick-start-guide få dig hurtigt i gang.
Først skal du dog installere Xdebug. Lad os finde ud af, hvordan du gør det.
1. Installer Xdebug til dit styresystem (OS)
Fordi Xdebug kan tilpasses til et vilkårligt antal opsætninger, vil den nøjagtige proces for hver enkelt være lidt anderledes. På OS-niveau er der et par forskelle:
- Windows: Dette er en noget kompliceret opsætningsproces, der involverer brug af en eksisterende PHP-fil og en installationsguide, hvorefter du henter den rigtige version til dit system.
- Linux: Metoden her er nok den mest ligetil: Du kan bruge en pakkehåndtering til at installere Xdebug eller PHP Extension Community Library (PECL).
- Mac: Denne metode er også enkel: Når du har installeret PECL, kan du køre
pecl install xdebug
fra en Terminal-instans. Du skal også have XCode-kommandolinjeværktøjer og PHP installeret på dit system.
De fleste brugere vil dog ikke ønske at holde sig til en instans af Xdebug på systemniveau. I stedet vil du ønske at integrere det i dit eget udviklingsmiljø.
2. Integrer Xdebug i dit udviklingsmiljø
Når du har installeret Xdebug til dit operativsystem, skal du forbinde det til dit miljø.
Der er så mange understøttede systemer og værktøjer her, at vi ikke kan komme ind på dem alle. Senere vil vi tilbyde dig instruktioner for både DevKinsta og PhpStorm. Alligevel er der masser af andre populære miljøer at vælge imellem. Nedenfor er nogle af vores bedste anbefalinger.
Variing Vagrant Vagrants (VVV)
VVV er et af de navngivne miljøer på Make WordPress-webstedet:
Den gode nyhed er, at VVVV allerede indeholder en version af Xdebug, men du skal aktivere den. Du kan gøre dette ved hjælp af Secure Shell (SSH) i et Terminal-vindue:
vagrant ssh -c "switch_php_debugmod xdebug"
Der er dog en lille smule af et ydelseshit, og du skal slå denne mulighed til igen, hvis du provisionerer dine websteder.
Laravel Valet
For nogle brugere repræsenterer Laravels Valet et næsten perfekt webudviklingsmiljø. Endnu bedre er det, at du kan integrere Xdebug med det.
For at gøre dette skal du oprette en konfigurationsfil til debuggeren. Du kan finde din egen sti ved hjælp af php --ini
på kommandolinjen, som vil returnere et par forskellige filstier:
Derefter skal du oprette en ny xdebug.ini-fil på stien til yderligere .ini-filer. I vores eksempel ligger den på /opt/homebrew/etc/php/7.4/conf.d.
Når du åbner denne nye fil, skal du også åbne stien til den indlæste konfigurationsfil (din primære php.ini-fil). Når begge er åbne, skal du tilføje følgende nederst i bunden:
- php.ini:
zend_extension="xdebug.so"
- xdebug.ini:
xdebug.mode=debug
Når du har gemt dine ændringer, skal du køre valet restart
fra terminalen og derefter tilføje phpinfo(); exit;
til en af dit websteds filer. Du skal kontrollere, om dette virker gennem et hurtigt sideindlæsning i browseren.
Bemærk, at det kan være nødvendigt at genstarte PHP ved hjælp af sudo brew services restart php
samt at kontrollere, at din systeminstallation af Xdebug er korrekt ved hjælp af php --info | grep xdebug
. Du vil bemærke de Xdebug-specifikke linjer i output:
Herfra kan du se på at indarbejde Xdebug i din foretrukne kodningseditor.
XAMPP
Ligesom Valet er der et par dele i processen for XAMPP. Windows- og macOS-versionerne har dog to forskellige processer.
Begynd med at installere XAMPP, og kør derefter en hurtig kontrol for at se, om filen php_xdebug.dll (Windows) eller xdebug.so (macOS) findes på dit system:
Hvis filen findes, kan du gå videre til konfigurationen. Ellers skal du først downloade enten den rigtige binære fil til Windows — en 64-bit fil til din foretrukne PHP-version — eller installere nogle flere afhængigheder, hvis du er på en Mac.
For Windows skal du omdøbe DLL-filen php_xdebug.dll og derefter flytte den til \xampp\php\ext-filstien. Åbn derefter filen \xampp\php\php.ini i din foretrukne kodeeditor, og tilføj følgende:
output_buffering = Off
I afsnittet [XDebug]
skal du tilføje de næste tre linjer:
zend_extension=xdebug
xdebug.mode=debug
xdebug.start_with_request=trigger
Når du har gemt dine ændringer, genstarter du Apache og tester for Xdebug.
På Mac skal du sikre dig, at du installerer Xcode-kommandolinjeværktøjerne ved hjælp af xcode-select --install
på en Terminal-instans. Derefter er der tre pakker, som du skal installere ved hjælp af Homebrew:
brew install autoconf automake libtool
I nogle tilfælde skal du også geninstallere XAMPP for at få både kerneprogrammet og “Developer Files” Du burde kunne geninstallere kun disse filer, men du bør først tage en backup af din eksisterende opsætning.
Derefter skal du navigere til downloadet for Xdebug-kildemappen på dit system og udpakke TGZ-filen. I et Terminal-vindue skal du navigere til denne mappe og køre følgende:
phpize
pecl install xdebug
Bemærk, at du muligvis også skal bruge sudo
her. Herfra kan du redigere XAMPP php.ini-filen. For de fleste macOS-installationer finder du den på /Applications/XAMPP/xamppfiles/etc/php.ini. I denne mappe finder du også stien til din xdebug.so-fil — noter den og brug den i stedet for filstiens placeholder i dette uddrag:
[xdebug]
zend_extension=/path/to/xdebug.so
xdebug.mode=develop,degug
xdebug.start_with_request=yes
For at teste, om dette virker, opretter du en ny xdebug_info.php-fil i hovedmappen htdocs XAMPP-mappen. Heri skal du tilføje følgende:
<?php
xdebug_info();
…opdater derefter Apache og test Xdebug i browseren.
Brug af PhpStorm med Xdebug
Når du har installeret Xdebug via OS og dit udviklingsmiljø, skal du også se selve debuggeren. Det gør du via din valgte kodeeditor eller dit integrerede udviklingsmiljø (IDE). Ligesom med dit miljø er der så mange at vælge imellem, og hvert af dem kan have en anden tilgang.
Når det er sagt, vælger mange udviklere at bruge JetBrains’ PhpStorm. Faktisk tilbyder PhpStorm “WordPress-aware assistance” — og det er også et populært valg af mange andre grunde.
JetBrains’ websted indeholder en komplet vejledning i at forbinde Xdebug og PhpStorm, men vi gennemgår dem her.
Først skal du navigere til siden Languages & Frameworks > PHP i ruden Preferences (Indstillinger). Her skal du åbne kebab-menuen More Items (Flere elementer) ved siden af dropdown-feltet CLI Interpreter (CLI-fortolker):
Dette vil vise nogle yderligere detaljer om din PHP-version og fortolker. Hvis du klikker på ellipsen Flere elementer ved siden af indstillingen Konfigurationsfil, vil du se de fulde stier til din php.ini-fil:
Du skal arbejde med denne PHP-fil næste gang for at fortsætte opsætningsprocessen.
Arbejde i filen php.ini
Den første opgave her er at redigere alle linjer, der har indflydelse på, hvordan Xdebug vil fungere med PhpStorm.
I php.ini-filen skal du kigge efter følgende linjer og enten fjerne dem eller kommentere dem ud:
zend_extension=<path_to_zend_debugger>
zend_extension=<path_to_zend_optimizer>
Disse linjer vil ikke være til stede i alle tilfælde, så vær ikke bekymret, hvis du ikke ser dem.
Derefter skal du tilføje følgende til 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>"
Der er et par ting, der skal bemærkes om denne kodesuite:
- Du har måske allerede en
[xdebug]
sektion, i så fald kan du udelade den første betegnelse. - Under
zend_extension
skal du muligvis tilføje den fulde sti til xdebug.so for at oprette forbindelse. - Selv om det kan ligne en placeholder, er det parameteren
xdebug.client_port
, som du indstiller den i din kode.
Når du har tilføjet disse, skal du gemme og lukke filen og derefter teste PHP-versionen fra kommandolinjen (ved hjælp af php --version
):
Hvis du har en fungerende version af Xdebug, vil den blive vist som en af PHP-udvidelserne. Du kan også tilføje phpinfo();
til en ny fil og teste dette i browseren.
Dette er stort set alt, hvad du behøver at gøre for at få Xdebug til at fungere som din standarddebugger med PhpStorm. Det sidste skridt, før du bruger det, er at installere en browser-hjælperudvidelse.
Installation af en browserhjælperudvidelse
Den sidste vigtige forbindelse, du skal lave, er mellem din browser og PhpStorm, hvilket opnås ved at aktivere step debugging på serveren. Selv om du kan gøre dette fra kommandolinjen ved hjælp af særlige GET
eller POST
værdier, er det mere ligetil at bruge en udvidelse.
Vi anbefaler at bruge den dedikerede Xdebug Helper-udvidelse. Du kan installere den i din foretrukne browser:
Hvis du ønsker at udforske andre udvidelser, tilbyder JetBrains-webstedet et par ekstra muligheder for de mest populære browsere.
Når du har installeret den valgte browserudvidelse, skal du ikke justere yderligere konfigurationsindstillinger. Herfra kan du begynde at bruge Xdebug med PhpStorm.
Brug af Xdebug
Selvom vi bruger PhpStorm her, vil du se et lignende layout og interface mellem forskellige IDE’er — selvom der også vil være nogle åbenlyse forskelle.
Der er nogle få koncepter, der tilsammen udgør hele debugging-oplevelsen:
- Breakpoints: Dette er de punkter, hvor Xdebug stopper for at lade dig inspicere output. Du kan indstille så mange af disse, som du ønsker.
- Lytte efter forbindelser: Du kan slå dette til og fra, selvom de fleste udviklere altid vil lade det være slået til.
- Debugging-skærmen: Det er her, du arbejder med de forskellige kodelinjer, variabler og parametre.
Det første skridt er at aktivere lytning — du vil ikke kunne debugge noget uden det. For at gøre dette skal du klikke på Run > Start Listening for PHP Debug Connections (Kør > Start lytte efter PHP Debug-forbindelser) i værktøjslinjen:
Som et alternativ kan du klikke på ikonet “telefon” i PhpStorm’s værktøjslinje:
En af disse muligheder vil starte lytningen efter forbindelser.
Herfra kan du begynde at indstille breakpoints i kodeeditorens riste. En rød prik angiver et breakpoint, som du kan klikke på for at aktivere:
Når du ønsker at debugge din kode, er den mest ligetil måde at begynde at lytte, sætte breakpoints og derefter gå til den specifikke side i din browser. Find ikonet for din udvidelse i browseren, klik derefter på det og vælg “Debug”-indstillingen:
Dette vil åbne debuggeren i PhpStorm og levere enten de gode eller dårlige nyheder:
Hvis du højreklikker på de forskellige værdier, attributter, parametre og variabler, kan du få adgang til en yderligere kontekstmenu. Dette giver dig masser af ekstra muligheder for at teste og debugge din kode:
Du kan f.eks. indstille forskellige værdier for variabler langs stien. Dette kan være et bevidst forsøg på at bryde din kode og se, hvad der sker, eller det kan være en måde at afprøve kode, der allerede har brug for en rettelse. Uanset hvad, giver det dig en fantastisk metode til at fejlfinde din kode uden at skulle ændre den først.
Hvordan Kinsta hjælper dig med at fejlfinde dit WordPress-websted
WordPress kommer med sit eget sæt af debugging-muligheder gennem WP_DEBUG
og andre værktøjer, såsom Query Monitor. Disse aktiverer en tilstand, hvor du begynder at se tidligere skjulte fejlmeddelelser overalt på dit websted og dashboard. Derfra kan du begynde at finde ud af, hvad problemet er.
Du kan også gemme disse fejlmeddelelser ved hjælp af WP_DEBUG_LOG
, hvilket giver dig en måde at dokumentere problemerne med dit websted på. Vi dækker, hvordan du sætter dette op i en anden artikel på bloggen. Det er nemt at opsætte via dit MyKinsta-dashboard (og skærmen Sites > Tools):
Hvis du parrer dette med det gratis DevKinsta-værktøj til lokale miljøer, har du også en måde at aktivere og deaktivere WP_DEBUG
med et enkelt klik for hvert websted, du sætter op:
Dette betyder, at du kan fange fejl på dit websted under udviklingen og sikre, at de ikke når frem til dit live-websted. Disse tilstande er også nemme at slå fra — hvilket er afgørende for både webstedets og brugernes sikkerhed.
Alle Kinsta-planer leveres også med det indbyggede Kinsta APM-værktøj, som er vores specialudviklede værktøj til overvågning af ydeevne til WordPress-websteder.
Kommando Cheat Sheet
Før vi afslutter dette indlæg, bør vi nævne genveje.
Ligesom mange andre programmer er der forskellige måder at navigere rundt i Xdebug (og PhpStorm) alene ved hjælp af tastaturet. Faktisk kan du endda bruge kommandolinjen til at debugge PHP-scripts.
Når Xdebug er oppe og køre, kan du bruge følgende kommandoer til at komme rundt:
Kommando | Genvej |
---|---|
Specifik port, der skal lyttes på (f.eks. [9003] ) |
-p [value] |
Sætter et breakpoint på den angivne linje for den angivne filsti. | breakpoint_set -t line file:///<path> -n <line> |
Kører dit script indtil slutningen, eller det næste breakpoint | run |
Går ind i den næste eksekverbare linje | step_into |
Lister variabler og værdier i det aktuelle område | context_get |
Viser værdien af den angivne egenskab | property_get -n <property> |
Mens din specifikke kodeeditor vil have sine egne dedikerede genveje, er fokus her på PhpStorm. Tag et kig på denne tabel med tastaturgenveje til brug af Xdebug med PhpStorm:
Kommando | Windows | macOS |
---|---|---|
Find handling | Ctrl + Shift + A | Skift + Cmd + A |
Åbn debuggeren | Skift + F9 | Ctrl + D |
Skift breakpoint | Kontrol + F8 | Cmd + F8 |
Træd ind i | F7 | F7 |
Træd over | F8 | F8 |
Visning af breakpoints | Ctrl + Shift + F8 | Shift + Cmd + F8 |
Genoptage programmet | F9 | F9 |
Evaluerer det aktuelle udtryk | Alt + F8 | Valgmulighed + F8 |
Heldigvis er der ikke meget at lære udenad her. Du skal åbne debuggeren, indstille breakpoints pr. linje, lytte efter forbindelser og køre dine scripts.
Hvis du imidlertid har brug for en genvej til en bestemt opgave, kan du bruge kommandoen PhpStorm Find Action:
Når du begynder at skrive i dette felt, får du vist en dynamisk liste over kommandoer og relaterede genveje. Du kan også finde en PDF-version af alle tastaturgenveje via menuen Hjælp > Tastaturgenveje PDF.
Hvis du vil have et mere realtidsorienteret kig på genveje, mens du arbejder med musen, tilbyder JetBrains plugin’et Key Promoter X:
Dette praktiske værktøj viser meddelelser om din seneste udførte handling sammen med den tilhørende tastaturgenvej. Når du først har lært og brugt genvejene, kan du udfase dette plugin og genoprette den værdifulde ejendom på din skærm.
Opsummering
Debugging er kommet langt fra sin ydmyge begyndelse; den omfatter nu et meget bredere anvendelsesområde, end dens forfædre kunne have forestillet sig. For at udføre et grundigt arbejde, når det gælder om at rette din PHP-kode, skal du bruge et kompetent værktøj. Der er mange fremragende udvidelser og værktøjer at vælge imellem, men Xdebug er en diskutabel frontløber.
Som vi har set, kan Xdebug tilpasse sig selv den mest eklektiske smag i kodeeditorer, og det er især godt, når det er parret med PhpStorm. Men uanset din opsætning vil der ofte være en version af Xdebug, der passer til dine behov. I det hele taget er det et kraftfuldt, fleksibelt og intuitivt værktøj at bruge.
Synes du, at Xdebug fortjener sin høje ros, eller er der et andet debuggingværktøj, som du foretrækker? Lad os vide det i kommentarfeltet nedenfor!
Skriv et svar