Blog technique Wizaplace

Debug pas à pas avec Xdebug, Sublime Text et Vagrant

Par Florent le 10 April 2017

Après une première semaine chargée, j’ai eu besoin de faire du debug pas à pas dans le code de Wizaplace, concernant un listener de l’évènement Symfony kernel.terminate. Ce code étant exécuté après que la réponse HTTP soit envoyée au client, impossible de se servir du bon vieux die.

tristesse

Après plusieurs heures d’investigation dans les paramètres de configuration de Sublime Text, Xdebug, et ne me laissant pas convaincre par mes collègues de passer sur PhpStorm, j’ai fini par trouver la configuration qui fonctionne.

Dans un premier temps il faut installer le plugin Xdebug Client, puis ajouter l’option globale :

{
    "close_on_stop": true
}

Cette option a pour effet de rétablir le layout que l’on avait avant la session de debug lorsque l’on arrête de débuger. Il faut savoir que par défaut l’option ide_key contient sublime.xdebug. Il faut donc paramétrer cette option dans le php.ini de notre vagrant :

[xdebug]
; permet d'activer le debug à distance
xdebug.remote_enable = 1
; Xdebug va se connecter au premier client qui fait une requête
xdebug.remote_connect_back = 1
; clé de l'IDE
xdebug.idekey = "sublime.xdebug"
; Essaye de démarrer une session de debug à chaque requête
xdebug.remote_autostart = 1

On utilise le remote_connect_back pour ne pas avoir à donner une adresse IP statique à Xdebug. Il faut aussi configurer le client Xdebug avec les informations spécifiques au projet, à savoir : la correspondance des chemins entre le code source sur l’éditeur et le code source dans la vagrant.

{
    "folders":
    [
        {
            "path": "apps/wizaplace",
            "folders_exclude_patterns": ["var/logs", "var/cache"]
        }
    ],
    "settings": {
        "xdebug":{
            "path_mapping": {
                "/vagrant" :"/Users/florentviel/apps/wizaplace"
            }
        }
    }
}

Nous avons absolument besoin de cette option, car elle sert à indiquer au serveur quels sont les fichiers qui contiennent les breakpoints. Sans cette option je ne pouvais pas placer de breakpoint dans mon code, par contre je pouvais faire du debug pas à pas avec l’option break_on_start du client, qui arrête l’exécution du code à la première ligne. C’est lorsque je me suis rendu compte que j’avais une typo dans le path_mapping que j’ai pu placer mon premier breakpoint.

Il faut aussi connaitre le déroulement d’une session de debug avec Xdebug (pour une page web) :

  • Ouverture du navigateur sur la page a debugger
  • Xdebug récupère l’IP source et essaye de se connecter au client de debug, par défaut <ip>:9000
  • Le code de la page est exécuté jusqu’au breakpoint placé s’il y en a un.

schema xdebug

Et pour finir un petit screenshot d’une session de debug :

debug session

Ce qu’on peut retenir, c’est qu’il n’est pas nécessaire d’utiliser un IDE pour faire du debug pas à pas avec Xdebug 😎. D’ailleurs le site officiel de Xdebug liste une majorité des clients existants, si vous n’utilisez ni Sublime Text ni PhpStorm.