I am building Laravel project now. Few days ago, I've reinstalled OS (Windows 10) and rebuild all development environment. Problem is updated version of Xdebug.
Debugging backend with version 2 of Xdebug worked well, but I have downloaded dll file which set with Xdebug v3 from xdebug.org/wizard, and according guide (something like I did before). But I cannot debug anymore.
Here is my launch.json file (old version)
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
And it seems there are some features updated from v2.
Something like above image.
I tried all cases I can but cannot found solution.. Anybody can help me? Any advice is appreciate. thanks.
IDE:
As the upgrade guide (https://xdebug.org/docs/upgrade_guide) shows, the first thing that has changed is the port number the IDE's should listen on for connections. This you have highlighted, but make sure you change it to 9003 in the json config file. This should be the only change you have to do in your IDE.
Next - Config of Xdebug:
There is this new setting in Xdebug: xdebug.mode (https://xdebug.org/docs/all_settings#mode). Its default value is develop and you have to change it (explicitly set it to debug) in order to put Xdebug in debug mode (you have to alter php.ini for this). Please see documentation for further details.
UPDATE:
As #LazyOne correctly suggested in the comments section, if you'd like to keep port 9000, you can skip modifying this in VS Code and instead set the port back to 9000 in the Xdebug settings: https://xdebug.org/docs/step_debug#client_port
This being said, the default port number was altered for a reason: https://bugs.xdebug.org/view.php?id=1848. You might want to adopt the new port number.
I solved the problem by deleting the cache using artisan command:
php artisan cache:clear
I don't know how this command solved the problem but I noticed that when I change the port to 9003 I still get error on port 9000 ! I think laravel has cached the port !
Related
I'm running a debugging session in Visual Studio Code. I was expecting two things to happen that didn't.
For a browser window to open when I launched 'run and debug'.
To see a list of variables and their values.
First, I downloaded the Xdebug extension.
Next, I set a breakpoint on my php file.
Lastly, I clicked the 'run and debug' button.
I'm hoping someone can offer some advice on where I'm going wrong.
Thanks,
Kyle
Check your ports, I recommend using some that you remember, example: default.
I recommend you install php with brew, since with MAMP, XAMP, etc. there is less information in case of error.
brew tap shivammathur/php
brew install shivammathur/php/php#7.3
This tool gave me a lot of headaches at work, however, on MacOs we have to do a lot of steps.
I recommend that you remember how to install it as it is, because sometimes Visual Studio Code changes the ports when updating.
Xdebugger installation
These three files are the most important to modify (with nano, vim, etc.)
php.ini
Location: /usr/local/etc/php/7.3/php.ini
...
; Local Variables:
; tab-width: 4
; End:
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_port = 9000
99-xdebug.ini
Location: /usr/local/etc/php/7.3/conf.d/99-xdebug.ini
zend_extension = "/usr/lib/php/extensions/no-debug-non-zts-20180731/xdebug.so"
xdebug.mode=debug
xdebug.start_with_request = yes
xdebug.remote_autostart = 1
Visual Studio Code
settings.json
Important: xdebug.remote_port, Listen for Xdebug, Launch currently open script are the same port.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
Once I performed all the configuration stuff, downliading the .dll, adding it to the ext path in xamp and to the php.ini etc.
[XDebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_port = 9003
zend_extension="C:\xampp\php\ext\php_xdebug.dll"
After adding both configs in vsCode:
1.- Installing the php debug extension
2.- Run->AddConfiguration->Listen for Xdebug
3.- Run->AddConfiguration->"Launch currently open script"
So both debug modes seem to be possible:
Surprisingly I can make the debug work if I "Launch currently open script".
De default config for the "Launch currently open script" is:
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 0,
"runtimeArgs": [
"-dxdebug.start_with_request=yes"
],
"env": {
"XDEBUG_MODE": "debug,develop",
"XDEBUG_CONFIG": "client_port=${port}"
},
}
But that did not work until I added runtimeExecutable":"C:\\xampp\\php\\php.exe.
For the case 1.- Listen for Xdebug, that is to debug the whole app without the need of selecting an specific file, I could not make it work. The launch.json is:
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003
}
I tried of course adding the runtimeExecutable":"C:\\xampp\\php\\php.exe, changing the ports, restarting apache and vs code and adding to de vs code settings the Allow Breakpoints Everywhere checkbox.
I am close, because for Launch current script mode works but when I launch vscode with the Listen for Xdebug option, my breakpoints are in place and my page is reloaded for check. Nothing happens and there are no errors in the vscode debug console.
Any idea of what needs to be done for the Listen for Xdebug to work and be able to debug the whole proyect with vscode?
Edit:
I also tried adding this options to my php.ini:
xdebug.mode = debug
xdebug.discover_client_host = 1
xdebug.start_with_request = yes
as recommended here
and the visualStudio php configuration Listen for XDebug 2 (Legacy)
Followed the intructions from the extension docs and I dont find what is wrong.
I've been working with VSCode + Docker in Windows for some years now, and managed to have a fully working dev environment without any issues.
Recently i setup a new development environment with WSL2. Moved all my projects, libraries, CLIs, etc, into WSL, using Docker Windows with WSL2 containers and VSCode on Windows with remote connection to WSL. Everything is working very smoothly and i like the fact i can have everything separated.
But recently i came across an issue that i'm unable to solve, i lost the ability to debug PHP files.
I'm using VSCode Remote WSL extension to work on my projects inside WSL, but when i try to debug, nothing happens.
I have tree debugging settings in my VSCode for each dev environment that i use (Windows, MacOS and WSL). All work except for the WSL. When i try to debug with WSL, literally nothing happens, no output erros, no debug console information, nothing...
Here are my VSCode debug settings:
{
"version": "0.2.0",
"configurations": [{
"name": "Listen for XDebug Win10",
"type": "php",
"request": "launch",
"port": 9000,
"log": true,
"externalConsole": false,
"pathMappings": {
"/var/www/project-a/api": "\\\\wsl$\\Ubuntu\\home\\ubuntu\\PROJECTS\\project-a\\api",
},
"ignore": [
"**/vendor/**/*.php"
]
},
{
"name": "Listen for XDebug MacOS",
"type": "php",
"request": "launch",
"port": 9000,
"log": true,
"externalConsole": false,
"pathMappings": {
"/var/www/project-a/api": "/Users/ricky/PROJECTS/project-a/api",
},
"ignore": [
"**/vendor/**/*.php"
]
},
{
"name": "Listen for XDebug WSL",
"type": "php",
"request": "launch",
"port": 9000,
"log": true,
"externalConsole": false,
"pathMappings": {
"/var/www/project-a/api": "/home/ubuntu/PROJECTS/project-a/api",
},
"ignore": [
"**/vendor/**/*.php"
]
},
]
}
What am i doing wrong? Any ideas on how to solve this issue?
### UPDATE: I've changed the original right answer to a new one. Although #romain-prevost's solution worked, I think #dark's approach is wayyy much simpler :)
Forget about the other answers. They are working but too complicated in my opinion.
The problem is, that you can't connect to xdebug.
The solution is to tell xdebug to set remote_host to host.docker.internal. Everything from there is available to localhost. Now you only have to listen inside Visual Studio Code to localhost via hostname.
Et voilà.
Now you can debug things invoked by your browser, inside your phpunit tests or within your commandline scripts.
Complete Example
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
"pathMappings": {
"/var/www/html/": "${workspaceRoot}"
},
"hostname": "localhost"
}
]
}
php.ini
[XDebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_host = host.docker.internal
xdebug.remote_port = 9000
Update for XDebug 3
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9003,
"pathMappings": {
"/var/www/html/": "${workspaceRoot}"
},
"hostname": "localhost"
}
]
}
php.ini
[XDebug]
xdebug.mode = develop
xdebug.start_with_request = yes
xdebug.client_host = host.docker.internal
xdebug.client_port = 9003
I have been struggling with PHP xdebug in Docker using WSL2 as well. It all comes down to the remote host.
What is your xdebug config in php.ini? You should set xdebug.remote_host to your WSL2 local IP address (which you can get in a terminal using hostame -I).
I have tried several times to set the remote host IP address in my Docker—composing a file to pass to the container on startup—but it always fails. Thanks to another StackOverflow answer, however, I have a solution for that too:
In WSL2, set an environment variable for your local IP in your .bashrc file. I have set mine to
export IP=$(hostname -I)
In your Docker compose file for the PHP service, pass the IP address as a new host with the extra_hosts key. For compose v3.2 it is
extra_hosts:
- "docker.host:${IP}"
You can look here for other compose versions: https://docs.docker.com/compose/compose-file/
Finally, edit your php.ini file for xdebug to have this line:
xdebug.remote_host=docker.host
Your container will be able to reach the WSL2 distribution with your docker.host and connect to the port you set for xdebug.
I spent a lot of time figuring this out, mainly because WSL2 was released officially a few days ago and there are not many guides about it.
It was not so complicated in the end, but without the extra_hosts key I could not get the WSL2 IP address to work. It was in the container and in xdebug config, but I always got an error about the resource being unavailable, so don't forget it 😁
The answer by #Romain-prevost is definitely the easiest and best way. If for some reason you can't get that to work, there is another alternative.
host.docker.internal will likely be reachable from within your container, but is a 192.* address by default, and is your Windows-based Docker IP. So you would need to set up forwarding from your Windows host into your WSL2 instance. This is outlined in this script in this issue at Github/WSL. You would simply change the ports to 9000 in that script. You could also use WSL2-Host to have a named entry in your hosts file for that IP and modify the script further to both restrict calling/receiving IPs.
I want to use VSCode's 'PHP Debug' plugin with Xdebug to debug PHP scripts.
But when I choose "Debug|Start Debugging F5" the little debug pop-up appears and I am stuck. Buttons for Pause, Restart, Stop are active. Buttons for Step over, into, out are inactive (greyed out). Nothing happens in the debug console.
(1) VSCode 1.42.1 is installed
(2) XAMPP v3.2.4 is up and running
(3) Xdebug is installed using the wizzard and pasting my phpinfo() data to determine the correct version. When I start 'admin' from XAMPP Control Panel and review phpinfo, the browser shows me (amongst many other things):
[...]
This program makes use of the Zend Scripting Language Engine:
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Xdebug v2.9.2, Copyright (c) 2002-2020, by Derick Rethans
[...]
(4) php.ini has
[XDEBUG]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.show_local_vars = 1
xdebug.remote_log = "C:\Program Files_\xampp\php\logs\xdebug.log"
zend_extension = "php_xdebug-2.9.2-7.4-vc15-x86_64.dll"
(please note that "Program Files_" is NOT the protected "Program Files" directory, XAMPP has write access as shown for point (9) below)
(5) the Windows path has C:\Program Files_\xampp\php; in it
(6) when I use Code Runner extension in VSCode to run a "Hello World.php" script is runs just fine
(7) launch.json for the VSCode debugger has
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000,
}
]
(8) my Windows firewall has an inbound rule to allow TCP traffic on port 9000.
(9) when I just run the code, xdebug.log (see php.ini) is updated with
[94396] Log opened at 2020-03-08 07:45:28
[94396] I: Connecting to configured address/port: localhost:9000.
[94396] E: Time-out connecting to client (Waited: 200 ms). :-(
[94396] Log closed at 2020-03-08 07:45:28
But when I use "Debug|Start Debugging F5" nothing happens in xdebug.log.
That is all the information that I thought relevant so far. Which leaves me like so:
me -> update_status("at wit's end")
Do you wizards out there have any idea where to dig? Which config file to tweak? Which log file to consult?
footnote: debugging of Python scripts in VSCode works just as expected.
#LazyOne's comment provided the clue and the tools to stumble upon the solution ...
And the answer turns out to be quite embarrassing.
Long story (how to check that VSCode is listening on port 9000)
start XAMPP, start VSCode
open your php script
set a breakpoint
open a Linux shell (I used Bash on Ubuntu on Windows)
run telnet 0.0.0.0 9000 or telnet localhost 9000 in the shell and observe the connection fail
root ~ $ telnet localhost 9000
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
root ~ $ telnet 0.0.0.0 9000
Trying 0.0.0.0...
telnet: Unable to connect to remote host: Connection refused
start debugging and see the frozen debug pop-up as described above
run telnet 0.0.0.0 9000 or telnet localhost 9000 in the shell and note the difference: you are connected to VScode!
root ~ $ telnet 0.0.0.0 9000
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
click the stop button on the frozen debug pop-up and observe in the shell
stop -i 1 Connection closed by foreign host.
root ~ $
Conclude that VSCode is indeed listening to both 0.0.0.0:9000 and localhost:9000.
scratch your head and go back to VSCode
start debugging
notice the orange status bar at the bottom that says "Listen to XDebug"
notice the drop down menu just below the menu bar that says "green arrow" and "Listen for XDebug"
explore the drop down and (re)discover the second configuration "Launch currently open script", realize/remember that your launch.json had 2 configurations
click the green arrow when "Launch currently open script" is selected, see a error pop up along the lines "listen EARDRINUSE: address already in use :::9000"
cancel the error message, stop debugging by clicking on the stop button of debug pop-up, notice that menu bar at the bottom turns blue
click the green arrow when "Launch currently open script" shows in the drop-down again ... and notice that debugging starts as expected
rejoice! praise #LazyOne for their help! thank the heavens for the stackoverflow community!
the "Listen for XDebug" configuration in launch.json is used to debug a script that was started from a browser session: (i) set your breakpoints in VSCode, (ii) start debugging with "Listen for XDebug" configuration, (iii) start the scripts by initiating a request i the browser, (iv) observe VSCode if a breakpoint is triggered while the request is processed
Short Story
Make sure that "Launch currently open script" is selected as configuration when you start debugging your php script in VSCode, see screenshot below.
Afterthought
I have changed my launch.json to
"configurations": [
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
},
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
}
]
This way the "Launch currently open script" is the default and will be used when I start debugging with "Debug|Start Debugging F5" from the main menu.
launch.json (default config):
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000,
}
]}
In php.ini is absolutely essential to include the directive xdebug.idkey=VSCODE, even though I haven't found any reference to it in the documentation.
[xDebug]
zend_extension="c:\xampp\php\ext\php_xdebug-2.9.8-7.3-vc15-x86_64.dll"
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.idekey=VSCODE
I just ran into this issue, where I was trying to listen to XDebug and nothing happened when I tried to hit F5 or Run/Debug...
It turns out some phantom folder had been added to my workspace (I had been running a bunch of test with some upgrade tool for the application I'm working on, so I guess that's where that came from?).
Removing that "extra" folder from the workspace was all I needed to do to be able to "run" the debug process again. Hopefully this can help someone else (not feel so dumb as I did) with a similar issue.
I am using Wamp on Windows 10 Pro 64bit. Firstly, PHP XDebug based debugging works fine on my normal Core PHP application in Visual Studio Code but when I start debugging a PhalconPhp (MVC) based application it stops at the first breakpoint and doesn't proceed, whatever I try - Continue (F5), Step Over (F10) etc. None of the keys or options work.
I have checked all similar issues and solutions - tried changing port from default 9000 to 9001 in php.ini and launch.json, added all extra configurations suggested in various posts although I am not doing remote debugging. Tried to setup a single and multiple breakpoints and also tried keeping them on various lines at start, middle or end of code.
php.ini
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back=1
xdebug.profiler_enable = On
xdebug.profiler_enable_trigger = On
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir ="R:/Temp"
xdebug.show_local_vars=1
xdebug.remote_port = 9000
xdebug.remote_log=R:\Temp\xdebug.log
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
There are no error messages. The debugger doesn't move an inch and stays stuck at first breakpoint. I can only restart execution in debugger, none of the other operations (Step In, Step Over, Continue...) work. I also have xdebug.log but don't see anything useful in it.
UPDATE: Debugging is working well for all Php programs including Phalcon with VSCode 1.36.1, XDebug 2.6.1, Php 7.2.14 on Windows 10. I think VSCode and XDebugger have some incompatibility issue for newer versions, but not sure.
In Setting->Debug you should uncheck "Break at first line in PHP scripts" item, this setting is for phpstorm but I think that's same for other IDE.
UPDATE
For VS code:
The launch.json file has the setting "stopOnEntry":true. Change this to false to prevent this. The docs for this can be found code.visualstudio.com/docs/python/debugging#_stoponentry
I started using VS Code debuging php (wordpress) recently. When I enable multiple breakpoints, it sometimes stuck like you described. When I enable only one breakpoint at any moment, it seems worked smoothly. Though it is not without hassle, it is better than no solution. I guess that when mutliple threads hit break points, they all try to talk to the xdebug and somehow deaklocked.