Déboguer PHP avec Visual Studio Code et XDebug sur le serveur. La configuration côté serveur va:Conversion de chemin d'extension VSCode PHP Debug, local vers le serveur
zend_extension=xdebug.so
xdebug.remote_enable=true
xdebug.remote_host=mybox
xdebug.remote_port=9000
xdebug.remote_log=/tmp/xdebug/xdebug-remote.log
xdebug.remote_autostart=1
xdebug.remote_handler=dbgp
xdebug.profiler_enable=0
xdebug.profiler_output_dir=/tmp/xdebug
La configuration launch.json va:
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
"localSourceRoot": "Y:\\",
"serverSourceRoot": "/home/seva/myproject",
"stopOnEntry":true
}
Maintenant, lorsque la configuration est comme ça, et je afficher une page de ce projet dans le navigateur , le débogueur s'arrête sur la première ligne PHP, et à partir de là, je peux définir des points d'arrêt et y accéder. Toutefois, si je définis un point d'arrêt dans le même fichier, définissez stopOnEntry sur false et chargez-le dans le navigateur, le point d'arrêt n'est pas atteint. Qu'est-ce que j'oublie ici?
EDIT: code très simple, instructions à une ligne, pas de lien symbolique, le mappage de chemin est donné à VS Code.
EDIT2: trouvé une ligne drôle dans le journal:
<- breakpoint_list -i 5
-> <response xmlns="urn:debugger_protocol_v1"
xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_list"
transaction_id="5">
<breakpoint type="line"
filename="file:///home/seva/y:/admin_main.php"
lineno="5" state="enabled" hit_count="0" hit_value="0" id="274990011">
</breakpoint>
<breakpoint type="line"
filename="file:///home/seva/y:/db.php"
lineno="770" state="enabled" hit_count="0" hit_value="0" id="274990010">
</breakpoint>
</response>
Notez le nom de fichier sur l'objet point d'arrêt: file:///home/seva/y:/admin_main.php. C'est un mash-up bizarre du chemin local et du chemin du serveur. Le fichier se trouve vraiment à /home/seva/myproject sur la boîte de serveur, qui est partagée sur SAMBA en tant que \\servername\myproject, puis mappée sur mon lecteur local Y :.
On dirait localSourceRoot et serverSourceRoot ne fonctionnent pas comme je pensais ...
EDIT3: quand je change localSourceRoot à myproject, l'entrée dans le journal a encore file:///home/seva/y:/admin_main.php. Je ne vois pas d'où vient Y: \, sauf que c'est le dossier que je suis en train d'éditer dans VS Code. Il y a donc une interaction amusante entre ces paramètres et le chemin du dossier actuel.
EDIT4: Je pense que le coupable est la fonction convertClientPathToDebugger() sous https://github.com/felixfbecker/vscode-php-debug/blob/5bfc474d681d5500d7b31d27bccdbfc08b88884e/src/paths.ts. Cela semble correct cependant - prenez le chemin relatif local, appliquez à la racine de serveur, obtenez le chemin de serveur.
Si seulement je pouvais parcourir que ...
Quel genre de lignes ce sont? Pour les instructions multi-lignes, la ligne réelle se situe quelque part au milieu. Il est donc préférable de définir uniquement les points d'arrêt sur les instructions simples/simples. Je ne sais pas comment VSC fonctionne exactement (utilisateur PhpStorm ici) mais peut-être est-ce lié d'une manière ou d'une autre aux mappings de chemin? Juste un rappel - xdebug (ou peut-être PHP lui-même) utilisera des chemins finaux/résolus alors que IDE/editor devrait utiliser le chemin tel quel. Donc, si vous avez des liens symboliques ou des choses comme ça sur le côté distant .. mieux prendre cela dans un compte. Est-ce que le fait de placer 'xdebug_break();' dans le code réel rompt le cas échéant avec cette option = 'false'? – LazyOne
Serait bien de voir les journaux xdebug pour les sessions "true" et "false" où les points d'arrêt sont touchés dans les deux cas. En ce moment, je suggère de créer un nouveau script simple avec quelques lignes simples, chaque instruction sur une nouvelle ligne, et voir comment il se comporte là. Quelque chose comme ' LazyOne