Christophe Le Bot

Pratique de la conception numérique

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 :

Oui, mais… Par défaut, Xdebug n’est pas en 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 :

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 :

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 !

Le serveur est maintenant configuré :

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

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.).

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

15 commentaires

Auteur
Patou
Date de publication
3 janvier 2009 à 21h45

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 ?


Auteur
Patou
Date de publication
3 janvier 2009 à 21h46

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.


Auteur
Christophe
Date de publication
28 janvier 2009 à 0h38

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.


Auteur
Metal3d
Date de publication
2 février 2009 à 16h17

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


Auteur
Christophe
Date de publication
4 février 2009 à 20h00

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.


Auteur
greg
Date de publication
9 février 2009 à 15h56

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 ???


Auteur
biowan
Date de publication
27 juillet 2009 à 11h33

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


Auteur
biowan
Date de publication
27 juillet 2009 à 11h54

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.


Auteur
biowan
Date de publication
27 juillet 2009 à 13h53

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.


Auteur
Christophe
Date de publication
1 septembre 2009 à 22h53

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


Auteur
senjy
Date de publication
16 janvier 2010 à 17h17

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 ?


Auteur
senjy
Date de publication
16 janvier 2010 à 18h10

Tout semble bien configuré, le naviageur se lance, mais je n’ai pas le variable.
http://www.flickr.com/photos/40682548@N05/4279403030
les options de pas a pas sont grisés.
une idée ?


Auteur
Christophe
Date de publication
18 janvier 2010 à 21h14

@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.


Auteur
Clem
Date de publication
10 août 2010 à 8h58

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


Auteur
Lionel
Date de publication
29 mars 2013 à 13h14

Merci beaucoup.


* Informations obligatoires