Installation de Xdebug, partie 1 : le module Xdebug

À ce jour, nous avons couvert beaucoup de terrain en ce qui concerne le travail avec WordPress et le débogage. Et cela est particulièrement vrai en ce qui concerne le travail avec les outils et plugins disponibles dans WordPress. Si vous rejoignez cette série en particulier, assurez-vous de suivre les publications suivantes :

• Lire et comprendre les journaux d’erreurs de WordPress, partie 1
• Lire et comprendre les journaux d’erreurs de WordPress, partie 2
• Débogage de base dans WordPress

Dans le post précédent, rappelez-vous que j’ai dit ce qui suit:

Mais si vous cherchez à entrer dans le monde du débogage professionnel et pratique à partir de votre IDE, il est important de comprendre le quoi, le comment et le pourquoi.

Et nous sommes enfin prêts à examiner ce que cela nécessite. Pour commencer, cependant, cela signifie que nous devons comprendre quelques éléments sur Xdebug, la terminologie, et avoir un IDE cohérent pour tous ceux qui lisent cette série particulière.

Cela va donc être divisé en deux parties.

• Tout d’abord, nous allons examiner la terminologie requise pour le débogage et nous assurer que nous avons une configuration IDE appropriée dans notre environnement de développement,
• Ensuite, nous allons voir comment nous assurer que nous avons correctement installé Xdebug, puis le connecter à notre environnement de développement afin que nous puissions le mettre au travail.

Si vous avez lu une variété de contenus sur ce blog au cours des dernières années, certains d’entre eux peuvent vous sembler familiers. Sinon, ce n’est pas grave. N’oubliez pas que l’objectif est de s’assurer que nous sommes tous au même niveau alors que nous progressons dans le travail mentionné ci-dessus et tout au long de la série.

Cela dit, commençons.

Installation de Xdebug, partie 1

Comme mentionné ci-dessus, cet ensemble de messages va servir l’un des deux objectifs qui peuvent être décrits succinctement (dont le second sera décrit dans le prochain article):

1. Terminologie de débogage
2. Installation d’un IDE

Bien que de nombreux lecteurs connaissent déjà une partie de la terminologie (surtout si vous avez déjà utilisé des outils côté client ou même des outils côté serveur), et que vous avez déjà un éditeur de choix, il est important de s’assurer que nous sommes travailler au moins avec une base cohérente.

Si vous avez confiance en vos compétences sur les deux points mentionnés ci-dessus, le prochain article sera probablement plus intéressant pour vous. Si, d’un autre côté, cela vous ouvre un nouveau territoire, cela devrait jeter les bases de tout ce dont vous avez besoin pour vous assurer que vous déboguez avec succès des projets dans WordPress.

De plus, cela garantira que vous disposez d’un ensemble cohérent d’outils avec lesquels travailler afin que nous puissions continuer à avancer avec un ensemble standard d’outils pour créer l’environnement de développement le plus productif possible.

1 Terminologie de débogage

En fonction de votre expérience, vous pouvez faire valoir qu’il existe entre cinq et sept termes, chacun étant lié au débogage. J’ai décrit alors avant dans d’autres messages sur ce site. À chaque fois, cependant, je l’ai fait avec une approche un peu différente du contenu.

Dans cet article, je vise à essayer de rendre cela aussi précis et précis que possible afin qu’il fournisse une référence cohérente que nous pourrons utiliser dans les articles (et dans le travail) à venir. Dans l’état actuel des choses, voici les termes que je pense que tout le monde devrait connaître en ce qui concerne leur débogueur.

1. Points d’arrêt. Ceux-ci peuvent être considérés comme les blocs fondamentaux du débogage. En termes simples, ce sont des endroits du code où vous souhaitez suspendre l’exécution afin de pouvoir examiner ce qui se passe dans le code. Cela a peut-être à voir avec les variables; peut-être que cela a à voir avec les fonctions, peut-être que cela a à voir avec autre chose. Quoi qu’il en soit, c’est important car vous dites au programme "hé, je veux empêcher le programme de s’exécuter ici sur cette ligne afin que je puisse enquêter sur l’état du programme".
2. Montres. Ce sont des appels de fonction, des variables ou d’autres endroits dans le code qui peuvent être définis de telle sorte que nous puissions littéralement voir les valeurs changer tout au long de l’exécution. Si nous parlons de fonctions, nous pourrions faire référence aux valeurs des arguments tels qu’ils sont définis et manipulés dans une fonction. Si nous parlons de variables, nous parlons de variables ; alors nous parlons des valeurs qu’ils détiennent à un moment donné pendant l’exécution du programme. Cela peut être lorsque nous définissons un point d’arrêt spécifique, ou lorsque nous parcourons le code et gardons un œil sur l’état de la variable tout au long de l’exécution du programme.
3. Commencez. Cette action indique simplement au débogueur de commencer à surveiller le serveur Web. Essentiellement, il garde un œil sur tout ce qui se passe dans le programme et, si des points d’arrêt sont définis, il est prêt à arrêter l’exécution et à nous permettre de jeter un œil à ce qui se passe avec l’état du programme. Vous pouvez techniquement démarrer une session de débogage et ne rien faire du tout. Ce n’est pas exactement productif, mais c’est possible.
4. Entrez dans. Supposons un instant que vous ayez un point d’arrêt défini juste au-dessus d’un appel de fonction ou sur un appel de fonction. Cela nous permet d’entrer dans la fonction pour surveiller la valeur de chaque argument, comment ils sont manipulés dans la fonction, ce que la fonction renvoie (le cas échéant) et tout ce qui se passe dans la fonction.
5. Enjambez. D’un autre côté, supposons que vous parcourez la fonction et que vous n’êtes pas sûr de vouloir plonger dans la fonction. Peut-être n’êtes-vous intéressé que par les valeurs renvoyées par la fonction ou par l’état du programme après l’exécution de la fonction, mais vous n’êtes pas intéressé par ce qui s’est passé dans la fonction. Essentiellement, vous le traitez comme une boîte noire. C’est ce que signifie enjamber une fonction. Autrement dit, vous laissez la fonction s’exécuter sans y entrer pour la regarder fonctionner.
6. Sortez. Cet aspect particulier du débogage est utile chaque fois que vous vous retrouvez dans une fonction et que vous êtes prêt à revenir à la ligne principale d’exécution car vous avez vu tout ce que vous devez voir. Peut-être avez-vous vu les valeurs d’une variable changer, peut-être avez-vous vu un algorithme faire suffisamment de travail pour savoir qu’il a fait ce que vous vouliez. Quoi qu’il en soit, cela vous permettra de sortir de la fonction, bien nommée, puis de passer à la
7. Arrêtez. Tout comme start indique au débogueur de commencer à écouter le serveur, en prêtant attention aux points d’arrêt et en affichant des informations sur la progression de l’application, stop fait exactement le contraire. Il indique au débogueur que nous avons fini d’écouter, de regarder et de prêter attention à l’état du programme. Cela ne signifie pas que le programme s’arrête – juste le débogueur. Donc, si vous avez fini de prêter attention à toutes les informations fournies par le débogueur, vous êtes probablement en mesure d’arrêter le débogueur.

Une dernière remarque que je voudrais faire est que PHP est unique en ce sens qu’il offre une variété de variables accessibles au public telles que $_GET , $_POST, $_REQUEST, etc. Ce sont aussi des variables qui sont à notre disposition et que nous pouvons surveiller. Ce n’est pas seulement limité à ce que nous avons écrit dans notre code.

Ceci est particulièrement utile lorsque nous examinons les données sur les rechargements de pages, les requêtes Ajax (comme lors des actions GET et POST), etc.

2 Installer Xdebug

Bien que cela ressorte probablement des articles précédents de cette série, je vais utiliser Visual Studio Code comme IDE de choix. Si vous n’en avez pas, alors c’est celui que je recommande. Si, toutefois, vous avez un IDE avec lequel vous êtes à l’aise, alors c’est celui que je recommande.

• Le code est toujours en développement,
• a une économie active d’extensions,
• fonctionne bien avec une variété de langages, d’outils, etc.,
• est léger et joue bien avec les différentes choses que nous pouvons être utilisées dans le développement WordPress (comme PHP, HTML et JavaScript).

De plus, Code dispose également d’un solide support pour Xdebug. Cependant, pour nous assurer que le débogueur est correctement installé, nous devons nous assurer que l’extension est installée avec notre installation de PHP, qu’elle est disponible sur notre système et qu’elle peut être exécutée dans notre IDE. Nous allons envisager de le faire, mais nous devons d’abord nous assurer que Xdebug est correctement installé.

Installation de Xdebug

L’installation de Xdebug est facile. Depuis votre session de terminal, vous devrez exécuter la commande suivante :

Une fois que vous l’avez fait, vous remarquerez que plusieurs choses se produisent dans la fenêtre du terminal au cours de l’installation. À moins que vous ne soyez particulièrement intéressé, vous n’avez pas à vous soucier de ce qu’il fait jusqu’à ce qu’il vous renvoie à l’invite de commande.

A ce stade, le module Xdebug a été installé ; cependant, vous devrez dire à PHP qu’il est installé et où il peut trouver le module.

Pour installer l’extension avec votre version actuelle de PHP, il est important de savoir quelle version de PHP vous avez installée. Si vous utilisez un gestionnaire de packages, il peut y avoir plusieurs versions et vous devrez indiquer au fichier de configuration de cette version particulière où trouver le module.

Inversement, si vous avez une seule version installée, vous devrez indiquer à une seule version de PHP où elle est installée. Tout d’abord, vous pouvez trouver où Xdebug existe sur le système de fichiers à l’aide de cette commande :

Ensuite, vous devrez mettre à jour le fichier de configuration de votre installation PHP. Pour ce faire, exécutez simplement php -v à partir de la ligne de commande et il vous dira quelle version vous utilisez. À partir de là, vous devrez localiser le fichier d’initialisation de la version de PHP que vous utilisez. Si, lors de l’exécution de php -v, vous revenez avec quelque chose comme ceci :

Cela nous indique que nous exécutons PHP 7.1.19 (bien que votre version puisse varier). À partir de là, nous savons rechercher un certain fichier de configuration PHP pour cette version de PHP. Pour ce faire, recherchez php.ini dans le répertoire /usr/local/etc/php/7.1/ de votre système (bien que le numéro de version exact puisse varier).

De là, ouvrez le fichier puis ajoutez la ligne de code suivante :

zend_extension="/usr/local/lib/php/pecl/20160303/xdebug.so"

Cela indiquera à PHP où réside Xdebug afin qu’il puisse être utilisé dans votre travail.

Tester l’installation

Pour vérifier que l’installation s’est bien déroulée, vous pouvez exécuter le code suivant dans votre terminal :

Et puis vous devriez voir quelque chose comme la sortie suivante à l’écran :

Notez que dans la capture d’écran ci-dessus, vous voyez ce qui suit :

avec Xdebug v2.6.0, Copyright (c) 2002-2018, par Derick Rethans

Cela signifie que le module a été installé et que PHP en est conscient.

Configuration de votre EDI

Dans le prochain article, nous verrons comment lier Xdebug à notre IDE. En supposant que vous avez suivi les étapes de cet article et que tout s’est bien passé, vous devriez être prêt à vous préparer au débogage des projets WordPress.

Tant que nous ne l’avons pas exécuté dans un IDE, cependant, ce n’est pas aussi utile (ou c’est plus difficile que nécessaire). Donc la semaine prochaine, nous verrons exactement comment faire cela.