Configurer Xdebug pour Eclipse PDT en utilisant un serveur de test distant

Fini le développement web approximatif ! Aujourd’hui, les applications web deviennent de véritables usines à gaz qu’il faut savoir maîtriser. Certains regrettent l’époque du développement procédural avec ses projets de moins de 2000 lignes de code, mais il faut se rendre à l’évidence : le web est la plate-forme, il a besoin d’applications riches, complexes et stables. Un exemple, Magento : 300.000 lignes de code…

Sans outils d’aide au développement, il n’est plus possible de garantir la qualité de son code. Heureusement, ils ne manquent pas, encore faut-il les installer et les configurer correctement.

Parmi les outils indispensables, le debugger et le profiler arrivent en tête. Ils permettent de tracer tout ce que le code source est censé faire : inclusions, chargement de données, valeurs de variables, temps d’exécution, contenu des objets, etc. Avec eux, on gagne déjà la moitié du temps de test ! Je devrais plutôt dire : sans eux, on ne fait pas de vrais tests !

Je vais prendre l’exemple d’une application web PHP développée avec Eclipse et son extension PDT (PHP Development Tools), en utilisant Xdebug comme debugger. Cela n’a rien d’original, des milliers de développeurs PHP utilisent cette configuration, mais je vais sortir des sentiers battus pour traiter un cas plus délicat, mais plus courant en entreprise : comment utiliser xdebug sous Eclipse quand mon serveur web de test n’est pas mon poste de travail, mais un serveur distant ?

L’environnement de travail

Imaginons donc cette configuration : un serveur web de test sous Linux Debian Etch et un poste de développement sous Windows. Rien de plus classique. J’aurais pu prendre un poste sous Linux, cela ne change rien à la suite. J’aurais aussi pu prendre un serveur web sous Windows (XAMP), mais je trouve tellement dangereux de faire des tests sous Windows pour une application qui sera hébergée par un serveur Linux que je préfère ne pas en parler…

On part du principe que PHP et Apache sont installés et actifs sur le serveur web. De même, Eclipse et PDT sont prêts sur le poste client.

Configuration du serveur web

Pour installer Xdebug, le plus simple est d’utiliser PECL. Mais pour utiliser PECL, il faut PEAR ! Et pour utiliser PEAR, il faut la version client de PHP ! Pas de panique, c’est tout simple : on prend sa console shell (en root) et on y va.

Installation de la version client de PHP :

apt-get install php5-cli

Installation de PEAR :

apt-get install php-pear

Pour éviter de se retrouver coincé par phpize, il faut aussi installer les paquets de développement PHP :

apt-get install php5-dev

On peut enfin installer Xdebug :

pecl install xdebug

Ensuite, on modifie le fichier de configuration de PHP pour activer Xdebug sur les applications web installées sur le serveur :

vi /etc/php5/apache2/php.ini

Dans le bloc Dynamic extensions, on ajoute la ligne suivante :

zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so

On enregistre, on ferme et on redémarre Apache :

/etc/init.d/apache2 restart

Si on fait un phpinfo() sur le serveur web, on obtient déjà un résultat encourageant :

xdebug dans phpinfo().

Oui, mais… Par défaut, Xdebug n’est pas en mode remote :

xdebug sans mode remote.

Or nous avons besoin du mode remote pour utiliser Xdebug depuis le poste client. Qu’à cela ne tienne ! Un autre petit tour dans la configuration PHP :

vi /etc/php5/apache2/php.ini

Dans le bloc Dynamic extensions, on ajoute la gestion du mode remote :

xdebug.remote_enable=1
xdebug.remote_host=192.168.1.2
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so

Attention, le paramètre xdebug.remote_host correspond à l’hôte distant… vu du serveur ! Il s’agit donc du poste de développement. Piège classique.

Après redémarrage d’Apache, le phpinfo() est déjà plus sympathique :

xdebug en mode remote.

C’est fini pour le serveur !

Configuration d’Eclipse

Il reste à configurer Eclipse pour envoyer les requêtes vers le serveur web. On ouvre les préférences (menu Windows > Preferences) et on choisit PHP > PHP Servers pour définir le serveur de test :

Configuration du serveur de test.

Il ne faut pas oublier les chemins (Path Mapping) pour faire le lien entre les deux machines. Si vous avez déjà créé un projet, vous pouvez directement le sélectionner comme chemin local (celui du poste client puisque, cette fois-ci, on est sous Eclipse !). Attention à un détail qui tue, le nom de votre projet ne doit pas contenir d’espace, sinon XDebug ne fonctionnera pas !

Configuration des chemins.
Le mapping des chemins.

Le serveur est maintenant configuré :

Le serveur configuré sous Eclipse.

Il reste à définir les paramètres par défaut du debugger PHP :

  • PHP Debugger : XDebug
  • Server : celui qui vient d’être configuré
  • PHP Executable : on le laisse non défini puisque nous sommes en mode distant
Configuration du debbuger sous Eclipse.

Cerise sur le gâteau, on oblige Eclipse à utiliser un navigateur web externe. Je choisis Firefox qui me permettra de tester l’interface avec d’autres outils (Firebug, Web Developper Tools, etc.).

Configuration du navigateur.

Voilà, c’est tout ! C’est un peu long, mais pas sorcier ! Maintenant on peut s’amuser et tester son code :

Xdebug en action dans Eclipse.

Commentaires

Patou

Merci pour cet article.

Mais dans le cas d’une équipe de DEV, comment ça se passe pour le remote_host ? Possibilité de préciser un ensemble d’adresse IP ?

3 janvier 2009, 21h45 · Répondre

Patou

xdebug.remote_host
Type: string, Default value: localhost
Selects the host where the debug client is running, you can either use a host name or an IP address.

3 janvier 2009, 21h46 · Répondre

Christophe

Dans le cas d’une utilisation commune d’un serveur de développement, on passe effectivement par le remote_host. La seule différence par rapport à l’article, c’est que cet hôte sera un proxy.

Si j’ai un peu de temps, je ferai un article complémentaire sur le sujet.

28 janvier 2009, 0h38 · Répondre

Metal3d

Ha bien, vraiment bien. Juste une question: tu forces un navigateur externe (ici firefox) mais j’aimerai bien utiliser le navigateur interne.

J’ai beau faire, ça refuse de fonctionner de la sorte, je suis en fait obligé de mettre firefox en navigateur… si tu as trouvé la solution, je suis preneur 🙂

En tout cas merci pour cet article

2 février 2009, 16h17 · Répondre

Christophe

Pour paramétrer par défaut le comportement du navigateur : menu Window > Preferences, arborescence General > Web Browser

Si ça ne suffit pas, voir peut-être dans Window > Web Browser.

4 février 2009, 20h00 · Répondre

greg

Impossible de faire fonctionner en mode remote : tout est bien configuré, j’ai mis debugclient sur mon poste, et je peux faire un telnet dessus depuis le serveur, mais je fais la requête en web, il ne se passe rien de spécial. Des idées ???

9 février 2009, 15h56 · Répondre

biowan

Je suis super intéressé. J’ignorais qu’on peut faire du debug sur 2 machines différentes et en plus 2 OS différents. C’est top, c’est justement ce qu’il me faut.
Alors, j’ai réussit par je ne sais plus comment à faire un breakpoint, il s’arrêtait bien au breakpoint en question. Mais il y a un truc dont je ne comprends pas bien. C’est la configuration du debug dans le menu Run > Debug configuration … Dans la partie URL, auto Generate, l’adresse du sous-dossier est totalement faux. J’ai donc mis l’adresse en dure, mais il se change automatiquement ? C’est peut-être un bug d’eclipse ?

Ma version PDT est 2.1

27 juillet 2009, 11h33 · Répondre

biowan

Encore une question, puisqu’on y est. On doit copier les fichiers nous même depuis notre workspace sur le serveur ?

Merci d’avance pour votre aide.

27 juillet 2009, 11h54 · Répondre

biowan

Bon ben, c’est bon, j’ai la solution. Tout fonctionne comme je voulais. Le problème avec Auto Generate a été résolu. Il ne faut pas mettre le chemin du sous-dossier dans l’édition du serveur web. Si le projet en question se trouve vraiment dans un sous-dossier du serveur web, il faut forcer la configuration dans Debug Configurations …, décocher Auto Generate et rajouter le dossier et le script correct dans le champs plus bas.

Encore merci pour ce tutorial en français, c’est vraiment pratique. Bonne continuation.

27 juillet 2009, 13h53 · Répondre

Christophe

Merci pour le détail de configuration que j’ai omis et pour les encouragements !

1 septembre 2009, 22h53 · Répondre

senjy

Merci, mais j’ai du mal a comprendre une chose.
Si on a un serveur qui contient les sources
Notre workspace qui en contient également des sources qui j’imagines doivent etre identique.
si je développe par exemple en méthode agile, je dois donc d’une part
– modifier le code source en local.
– faire une synchronisation (via FTP ou autre)
– lancer le debuggage

et ainsi de suite.
Donc il y a un aller retour serveur-poste client qui est fastidieux.

Peut on, si oui comment ? faire pour que le workspace est le meme docroot(racine) du serveur pour un développement en local. Cela économiserait il pas des allez retour ?

16 janvier 2010, 17h17 · Répondre

Christophe

@senjy
Ah oui… Pour que ça fonctionne, c’est mieux d’avoir le même dossier pour le workspace ET le docroot ! Dans le cas d’un serveur distant, un montage de volume réseau suffit. Si le poste est sous Windows et le serveur sous Linux, Samba fera parfaitement l’affaire.

18 janvier 2010, 21h14 · Répondre

Clem

Dans le cas d’un site utilisant du URL rewriting, il n’y aurait pas un soucis avec le path mapping?

10 août 2010, 8h58 · Répondre

Lionel

Merci beaucoup.

29 mars 2013, 13h14 · Répondre

Ajouter un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *