Si vous trouvez cette extension utile, si elle vous aide à résoudre vos problèmes et si vous appréciez le soutien apporté ici, envisagez de parrainer notre travail.
Installez l'extension: appuyez sur F1
, Type ext install php-debug
.
Cette extension est un adaptateur de débogage entre le code VS et XDebug par Derick Rethans. XDebug est une extension PHP (un fichier .so
sur Linux et un .dll
sur Windows) qui doit être installé sur votre serveur.
Installer xdebug Je vous recommande fortement de créer un fichier test.php
simple, mettez un phpinfo();
instruction là-dedans, puis copiez la sortie et collez-la dans l'assistant d'installation XDebug. Il l'analysera et vous donnera des instructions d'installation sur mesure pour votre environnement. En bref:
Sur Windows: Téléchargez la DLL précompilée appropriée pour votre version PHP, votre architecture (64/32 bits), la sécurité de thread (TS / NTS) et la version du compilateur Visual Studio et la placez dans votre dossier d'extension PHP.
Sur Linux: Téléchargez le code source en tant que tarball ou le clonez avec Git, puis compilez-le. Ou voyez si votre distribution propose déjà des packages prédéfinis.
Configurez PHP pour utiliser xdebug en ajoutant zend_extension=path/to/xdebug
à votre php.ini. Le chemin d'accès de votre php.ini est illustré dans votre sortie phpinfo()
sous "Fichier de configuration chargé".
Activez le débogage à distance dans votre php.ini
:
Pour xdebug v3.xx:
xdebug.mode = debugxdebug.start_with_request = oui
Pour xdebug v2.xx:
xdebug.remote_enable = 1xdebug.remote_autostart = 1xdebug.remote_port = 9000
Il existe d'autres moyens de dire à XDebug de se connecter à un débogueur distant, comme les cookies, les paramètres de requête ou les extensions de navigateur. Je recommande remote_autostart
(XDebug v2) / start_with_request
(XDebug v3) car il "fonctionne juste". Il existe également une variété d'autres options, comme le port, veuillez consulter la documentation XDebug sur le débogage à distance pour plus d'informations. Veuillez noter que le port xdebug par défaut a changé entre XDebug V2 à V3 de 9000 à 9003.
Si vous effectuez un développement Web, n'oubliez pas de redémarrer votre serveur Web pour recharger les paramètres.
Vérifiez votre installation en vérifiant votre sortie phpinfo()
pour une section xdebug.
Dans votre projet, allez au débogueur et appuyez sur l'icône Little Gear et choisissez PHP . Une nouvelle configuration de lancement sera créée pour vous avec trois configurations:
Écoutez XDebug Ce paramètre commencera simplement à écouter sur le port spécifié (par défaut 9003) pour XDebug. Si vous avez configuré XDebug comme recommandé ci-dessus, chaque fois que vous faites une demande avec un navigateur à votre serveur Web ou lancez un script CLI XDebug se connectera et vous pouvez vous arrêter sur des points d'arrêt, des exceptions, etc.
Lancez actuellement le script ouvert Ce paramètre est un exemple de débogage de CLI. Il lancera le script actuellement ouvert en tant que CLI, affichera toutes les sorties stdout / stderr dans la console de débogage et termine la session de débogage une fois le script qui sera sorti.
Lancez le serveur Web intégré Cette configuration démarre le serveur Web intégré PHP sur un port aléatoire et ouvre le navigateur avec la directive serverReadyAction
. Le port est aléatoire (localhost: 0) mais peut être changé pour un port fixe souhaité (ex: localhost: 8080). Si un script de routeur est nécessaire, ajoutez-le avec la directive program
. Les directives PHP / XDEBUG supplémentaires déclenchent le débogage de chaque chargement.
Il existe également des configurations pour les installations XDebug V2 (héritage).
Des informations plus générales sur le débogage avec le code VS sont disponibles sur https://code.visualstudio.com/docs/editor/debugging.
Remarque: vous pouvez même déboguer un script sans
launch.json
. Si aucun dossier n'est ouvert et que la barre d'état du code VS est violet, en appuyant surF5
commencera le script ouvert avec des paramètres spécifiques xdebug3. Si l'exécutable PHP n'est pas dans le chemin, vous pouvez lui fournir le réglagephp.debug.executablePath
. Pour que le débogage fonctionne, XDebug doit toujours être correctement installé.
request
: toujours "launch"
hostname
: l'adresse à lier lors de l'écoute de xdebug (par défaut: toutes les connexions IPv6 si disponibles, sinon toutes les connexions IPv4) ou un socket de domaine UNIX (préfixe avec unix://
) ou Windows Pipe ( ?pipename
) - ne peut pas être combiné avec port
port
: le port sur lequel écouter xdebug (par défaut: 9003
). Si le port est défini sur 0
un port aléatoire est choisi par le système et qu'un espace réservé ${port}
est remplacé par le port choisi dans env
et runtimeArgs
.
stopOnEntry
: s'il faut se casser au début du script (par défaut: false
)
pathMappings
: une liste de chemins de serveur mappant vers les chemins de source locaux de votre machine, voir "Débogage à distance de l'hôte" ci-dessous
log
: s'il faut enregistrer toutes les communications entre le code vs et l'adaptateur à la console de débogage. Voir le dépannage plus bas.
ignore
: un tableau facultatif de modèles globaux dont les erreurs doivent être ignorées (par exemple **/vendor/**/*.php
)
ignoreExceptions
: un tableau facultatif de noms de classe d'exception qui doivent être ignorés (par exemple BaseException
, NS1Exception
, *Exception
ou **Exception*
)
skipFiles
: un tableau de modèles glob, pour sauter lors du débogage. Les modèles et négations d'étoiles sont autorisées, par exemple, **/vendor/**
ou !**/vendor/my-module/**
.
skipEntryPaths
: un tableau de modèles glob, pour détacher immédiatement et ignorer pour déboguer si le script d'entrée correspond (exemple **/ajax.php
).
maxConnections
: Acceptez uniquement ce nombre de séances de débogage parallèle. Des connexions supplémentaires seront supprimées et leur exécution se poursuivra sans débogage.
proxy
: paramètres de proxy DBGP
enable
: pour activer l'enregistrement proxy défini sur true
(par défaut est `faux).
host
: l'adresse du proxy. Prend en charge le nom d'hôte, l'adresse IP ou la prise de domaine UNIX (par défaut: 127.0.0.1).
port
: le port où l'adaptateur s'inscrira avec le proxy (par défaut: 9001
).
key
: une clé unique qui permet au proxy de faire correspondre les demandes à votre éditeur (par défaut: vsc
). La valeur par défaut est tirée des paramètres VScode php.debug.idekey
.
timeout
: le nombre de millisecondes à attendre avant d'abandonner la connexion au proxy (par défaut: 3000
).
allowMultipleSessions
: si le proxy doit transmettre plusieurs sessions / connexions en même temps ou non (par défaut: true
).
xdebugSettings
: vous permet de remplacer les paramètres de débogage à distance de XDebug pour amener l'accord XDebug à vos besoins. Par exemple, vous pouvez jouer avec max_children
et max_depth
pour modifier le nombre maximum d'enfants de tableau et d'objet qui sont récupérés et la profondeur maximale dans des structures telles que les tableaux et les objets. Cela peut accélérer le débogueur sur les machines lentes. Pour une liste complète des noms de fonctionnalités qui peuvent être définis, veuillez vous référer à la documentation XDebug.
max_children
: Nombre maximum d'enfants de tableau ou d'objet pour récupérer initialement
max_data
: quantité maximale de données variables à récupérer initialement.
max_depth
: profondeur maximale que le moteur de débogueur peut retourner lors de l'envoi de tableaux, de hachages ou de structures d'objets à l'IDE (il ne devrait pas être nécessaire de changer cela car la profondeur est récupérée par progression, une grande valeur peut entraîner la suspension de l'IDE).
show_hidden
: Cette fonctionnalité peut être définie par l'IDE si elle veut avoir des informations internes plus détaillées sur les propriétés (par exemple, les membres privés des classes, etc.) zéro signifie que les membres cachés ne sont pas montrés à l'IDE.
xdebugCloudToken
: Au lieu d'écouter localement, ouvrez une connexion et inscrivez-vous avec Xdebug Cloud et acceptez les séances de débogage sur cette connexion.
stream
: permet d'influencer les flux DBGP. Xdebug ne prend en charge que stdout
voir dbgp stdout
stdout
: Redirection STDOUT Stream: 0 (Disable), 1 (Copie), 2 (Redirection)
Options spécifiques au débogage de la CLI:
program
: chemin vers le script qui devrait être lancé
args
: Arguments transmis au script
cwd
: Le répertoire de travail actuel à utiliser lors du lancement du script
runtimeExecutable
: chemin vers le binaire PHP utilisé pour lancer le script. Par défaut, celui sur le chemin.
runtimeArgs
: arguments supplémentaires à passer au binaire PHP
externalConsole
: lance le script dans une fenêtre de console externe au lieu de la console de débogage (par défaut: false
)
env
: Variables d'environnement à passer au script
envFile
: chemin facultatif vers un fichier contenant des définitions de variables d'environnement
Point de rupture de ligne
Points de rupture conditionnels
Appuyez sur le nombre de points d'arrêt: prend en charge les conditions comme >=n
, ==n
et %n
Points de rupture de la fonction
Passez-vous, interminez-vous, sortez
Break on Entry
Commencez par arrêter l'entrée (F10 / F11)
Rompre sur les exceptions et les erreurs / avertissements non revêtus
Demandes multiples et parallèles
Traces de pile, variables de portée, superglobaux, constantes définies par les utilisateurs
Arrays et objets (y compris le nom de classe, les propriétés privées et statiques)
Console de débogage
Montres
Définir les variables
Courir comme CLI
Courir sans déboguer
Enregistrement de proxy DBGP et support de non-inscription
Prise en charge du cloud xdebug
Pour déboguer une application en cours d'exécution sur un hôte distant, vous devez dire à XDebug de vous connecter à une IP différente de localhost
. Cela peut être fait en définissant xdebug.client_host
à votre IP ou en définissant xdebug.discover_client_host = 1
pour faire en sorte que xdebug se connecte toujours à la machine qui a fait la demande Web. Ce dernier est le seul paramètre qui prend en charge plusieurs utilisateurs qui déboguent le même serveur et «fonctionnent simplement» pour les projets Web. Encore une fois, veuillez consulter la documentation XDebug sur le sujet pour plus d'informations.
Pour faire de VS Code Map Les fichiers du serveur vers les bons fichiers de votre machine locale, vous devez définir les paramètres pathMappings
dans votre lancement.json. Exemple:
// Server -> local "pathmappings": {"/ var / www / html": "$ {workspacefolder} / www", "/ app": "$ {workspacefolder} / app"}
Veuillez également noter que la définition des options de débogage de CLI ne fonctionnera pas avec le débogage à distance de l'hôte, car le script est toujours lancé localement. Si vous souhaitez déboguer un script CLI sur un hôte distant, vous devez le lancer manuellement à partir de la ligne de commande.
Le débogueur peut s'inscrire à un proxy DBGP avec une clé IDE. Le proxy sera ensuite transmis à l'IDE uniquement les sessions DBGP qui ont cette clé IDE spécifiée. Ceci est utile dans un environnement multi-utilisateur où les développeurs ne peuvent pas utiliser le même port DBGP en même temps. Une configuration minutieuse est nécessaire que les demandes au serveur Web contiennent la touche IDE correspondante.
La mise en œuvre officielle du DBGPProxy.
Une extension du navigateur d'assistance XDEBUG est également recommandée. Là, la touche IDE côté demande peut être facilement configurée.
Posez une question sur Stackoverflow
Si vous pensez avoir trouvé un bug, ouvrez un problème
Assurez-vous que la dernière version de cette extension et XDebug sont installées
Essayez un fichier PHP simple pour recréer le problème, par exemple à partir du TestProject
Définir "log": true
dans votre lancement.json et observer le panneau de console de débogage
Dans votre php.ini, définissez xdebug.log = /path/to/logfile
(assurez-vous que votre serveur Web a des autorisations d'écriture sur le fichier)
Contacter Twitter @damjancvetko
Pour pirater sur cet adaptateur, clonez le référentiel et ouvrez-le dans le code vs. Vous avez besoin de NodeJs avec NPM installé et sur votre chemin. Un PHP et Xdebug récent doivent également être installés et sur votre chemin.
Installez les packages NPM en exécutant npm install
sur la ligne de commande dans le répertoire du projet ou en sélectionnant Terminal / Run Task... / npm / npm: install
dans le menu de code vs.
Exécutez le processus de build / watch soit en exécutant npm run watch
sur la ligne de commande dans le répertoire du projet ou en sélectionnant Terminal / Run Build Task...
dans le menu du code vs.
Démarrez l'adaptateur de débogage en ouvrant la barre latérale de l'exécution et du débogage, en sélectionnant la configuration Debug adapter
et en cliquant sur la flèche Green Run (ou en frappant F5
). L'adaptateur compilé s'exécutera en "mode serveur" et écoute sur le port TCP 4711.
Exécutez une instance séparée de VS Code, appelé "Extension Development Host" en exécutant code testproject --extensionDevelopmentPath=.
sur la ligne de commande dans le répertoire du projet ou sélectionner l' Launch Extension
Exécuter et déboguer la configuration et appuyer sur la flèche d'exécution verte. Un autre raccourci consiste à exécuter npm run start
. Vous pouvez également exécuter une construction d'initiés de code vs pour tester les fonctionnalités plus récentes.
Dans l'instance "Extension Development Host", ouvrez .vscode/launch.json
et Uncomment, la ligne de configuration debugServer
. Exécutez votre session de débogage PHP en sélectionnant la configuration souhaitée et en appuyant sur F5
. Vous pouvez maintenant déboguer le testproject comme spécifié ci-dessus et définir des points d'arrêt dans votre première instance de code VS pour parcourir le code de l'adaptateur.
Plus d'informations sur les extensions de test peuvent être trouvées sur https://code.visualstudio.com/api/working-with-extensions/testing-extension.
Les tests sont écrits avec Mocha et peuvent être exécutés avec npm test
ou à partir de Terminal / Run Task... / npm: test
. Lorsque vous soumettez un PR, les tests seront exécutés en CI sur Linux, MacOS et Windows contre plusieurs versions PHP et XDEBUG.
Avant de soumettre un PR, Run npm run lint
Terminal / Run Tasks... / npm: lint
.