Utiliser les points d'arrêt en PHP avec xdebug
Certains langages de programmation permettent d'utiliser des fonctions de débuggage interactives comme :
- Les points d'arrêt (breakpoint)
- La pile d'appel (call stack)
- Exécution pas à pas : step into, step over et step out
C'est notamment le cas sur des technologies comme .NET (avec VisualStudio) ou Java (avec Netbeans ou Eclipse). Cette méthode de debuggage est nettement moins répendue en PHP, en grande partie parce que ça n'est pas dans la "culture" des développeurs PHP, qui sont plutôt habitués à utiliser des méthodes "artisanales" comme print_r ou var_dump.
Pourtant, peu de développeurs PHP savent qu'on peut utiliser des points d'arrêt et tout le reste en PHP, grâce à l'extension PHP XDebug. Cette extension permet de faire communiquer le serveur PHP avec un éditeur de texte ou un IDE, et c'est grâce à ce mécanisme qu'on peut demander au serveur PHP de s'arrêter à telle ou telle ligne, et qu'on peut voir les variables locales et la pile d'appel à chaque point d'arrêt.
La première étape est de télécharger et d'installer XDebug sur votre serveur PHP si ça n'est pas déjà fait. Lisez ceci pour voir comment installer XDebug.
Activer et configurer le remote debugger XDebug
Ouvrez le fichier de configuration de PHP : php.ini (ex: C:\EasyPHP\conf_files\php.ini), pour y copier-coller ces lignes qui permettent d'activer et de configurer le remote debugger :
xdebug.extended_info=1 xdebug.remote_enable = on xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_host=127.0.0.1 xdebug.remote_port=9000 xdebug.remote_autostart=1
XDebug et l'éditeur de texte communiquent par le réseau, et plus précisément le protocole DBGp. L'éditeur de code joue le rôle de serveur, et le serveur PHP est le client, qui va se connecter au serveur (éditeur de texte) lorsque l'exécution d'un script démarre et rencontre un point d'arrêt.
L'adresse IP et le port sont donc les informations qui permettent à l'extension XDebug présente sur le serveur PHP de se connecter à l'éditeur de texte.
Le paramètre xdebug.remote_autostart permet de lancer une session de debuggage à chaque exécution de script. Par défaut cette option est désactivée, du coup on est obligé de passer un paramètre XDEBUG_SESSION_START en GET dans l'URL du script à debugger, et ce n’est pas pratique (cf la doc @ Starting The Debugger).
Configurer la connexion à XDebug dans Notepad++
Une fois le serveur est prêt, il reste à configurer votre éditeur de texte (ou votre IDE). Les IDE (comme Netbeans) gèrent généralement le debuggage nativement.
En ce qui me concerne je n'utilise pas d'IDE, j'utilise Notepad++ et il existe un plugin pour Notepad++ qui permet de faire du debuggage avec le protocole DBGp : DBGP Plugin, donc je vais montrer ici comment l'utiliser. Vous ne devriez pas avoir trop de difficulté à trouver comment faire si vous utilisez un autre éditeur (pensez à partager ces infos en commentaire au passage).
Téléchargez et installez le plugin (en plaçant la dll dans le dossier plugins de Notepad++ : C:\Program Files (x86)\Notepad++\plugins\dbgpPlugin.dll), puis lancez Notepad++.
Dans Notepad++, allez dans le menu Compléments > DBGp > Debugger, ce qui va afficher l'interface.
Si vous voulez en savoir plus c'est par ici : nombre maximum de 256 colonnes sur excel.
Cliquez sur le petit bouton rouge pour ajouter un point d'arrêt à la ligne courante, puis lancez le script (en chargeant la page dans votre navigateur web, comme d'habitude).
Le chargement de la page va être bloqué, et si vous allez voir dans l'éditeur de texte, vous verrez que l'exécution du script est stoppée au niveau du point d'arrêt :
Dans le panneau Local context on peut voir la liste des variables locales (à la ligne courante). La pile d'appels indique comment on est arrivé à cette ligne, quelle suite d'appel de fonction nous a conduits ici (très utile pour pister du code et comprendre comment marche une application).
Pour poursuivre l'exécution, il suffit de cliquer sur l'icône en forme de flèche. L'exécution repart alors, et s'arrêtera soit à la fin du script, soit au prochain breakpoint rencontré.
On peut aussi utiliser les fonctions de debuggage pas-à-pas qui servent à exécuter du code ligne par ligne :
- Step into : passe sur chaque ligne de code exécutée
- Step over : reste dans la fonction courante (ça évite de "plonger" dans tous les appels de fonctions)
- Step out : sort de la fonction courante, pour revenir à la ligne de code qui a appelé cette fonction
Encore faim ? allez lire ça : effet 3d, ruban, reflet !
