I hope somebody here can help me with my issue:
I recently gotten into my first PHP project and need to set up debugging. I'm aware many people had the same problem before me but I struggle to find a solution.
I need to set up PhpStorm with Xdebug and with all settings made its still not working and when I start my debug session i get stuck at this with no further information:
This is my project setup:
Docker Webapp with Xdebug: 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp
PhpStorm PHP Debug Settings:
Xdebug settings from phpinfo():
Listening to debug connections in PhpStorm is on, starting a debug session create a session via GET: https://localhost/?XDEBUG_SESSION_START=16957 but all my breakpoints are ignored.
Trying to get more information I ran netstat:
Can anyone tell me what I am missing here?
Thank you very much in advance!
Don't use run/debug configurations for web debugging, it's counter-productive. You can initiate debugging connections from the browser directly using zero-configuration debugging.
Disable xdebug.remote_connect_back, it brings more harm than profit, especially with Docker.
xdebug.remote_host is not supposed to be localhost when you are using Docker, this way, the container is trying to send the debug data to itself instead of the host machine. It seems that you are using macOS and Docker for Mac, the correct hostname would be host.docker.internal in such a case.
If after you initiate a debugging session from the browser PhpStorm still cannot catch a connection, we'll need to take a look at the Xdebug log as #LazyOne suggested.
A blog post showing Docker in PhpStorm basics: https://blog.jetbrains.com/phpstorm/2018/08/quickstart-with-docker-in-phpstorm/
i used this setting and it worked :)
xdebug.remote_port=9000
xdebug.idekey=PHPSTORM
xdebug.default_enable=1
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.profiler_enable=0
xdebug.profiler_output_dir="/var/www/html"
xdebug.var_display_max_depth=20
xdebug.remote_host=host.docker.internal
xdebug.remote_enable=1
xdebug.remote_connect_back=0
with launch.json in vscode
"name": "Listen 9000",
"type": "php",
"request": "launch",
"log": true,
"externalConsole": false,
"pathMappings": {
"/var/www/html": "/Users/folder/project/src"
},
"port": 9000,
With docker-compose.yml:
Related
I am trying to implement Xdebug in my VSCode for WordPress project. I am using XAMPP and PHP 7.4.15. I have set up Xdebug on my computer (Windows 10).
launch.json
{
// 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": 9003
}
]
}
php.ini
[XDebug]
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_port=9003
xdebug.client_host = localhost
zend_extension="G:\xampp\php\ext\php_xdebug-3.0.3-7.4-vc15-x86_64.dll"
I have installed PHP Debug Extension by Felix Becker on my VSCode. Restarted my XAMPP and VSCode several times.
I have made several breakpoints on index.php file of my theme (Currently active).
I set the setting Listen for xDebug (wptest). But, When I run the debug, and refresh my index.php page, it shows me following error:
Any lead on this?
Xdebug is initiating a break-point here, likely because it was instructed to do so by VSCode. You can verify this by checking the breakpoint_set lines inside the Xdebug log file, which you can create by setting xdebug.log=/tmp/xdebug.log in php.ini.
On the bottom left of your last screenshot, you can see that there is a tick set for "Everything". For the VS Code plugin that means setting an Xdebug break-point on *, which includes every exception, including ones that are caught. If you un tick the box, Xdebug should no longer generate a break-point to interrupt your code here.
I am not sure what the issue is, it just doesn't work.
The routing seems to work, I have a server name in my nginx conf file. e.g. test.com. that works.
My project is in the root of ubuntu and not in the mount folders.
I am not sure what else to try.
xdebug.ini
[XDebug]
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.remote_port=9002
xdebug.remote_handler=dbgp
xdebug.remote_connect_back=0
xdebug.remote_host=soapboxtest.com
xdebug.idekey=VSCODE
xdebug.remote_autostart=1
xdebug.remote_log=/usr/local/etc/php/xdebug.log
launch.json
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9002,
"log": true,
"externalConsole": false,
"pathMappings": {
"/var/www": "${workspaceRoot}"
},
"ignore": [
"**/vendor/**/*.php"
]
},
Request cookies
"XDEBUG_SESSION" => "VSCODE"
Dockerfile
FROM php:fpm-alpine3.11
...
RUN pecl install xdebug
RUN docker-php-ext-enable xdebug
...
This happened to me also and found that XDEBUG is not looking for the Docker Daemon Host. Got it fixed by adding:
"hostname": "0.0.0.0"
As part of the general options of the launch.json on VS Code.
After had a colleague helping me to configure Xdebug to listen out of WSL Remote environment from VSCode, I´ve looked up for an option that is opened when you click on the WSL Remote icon on the lower left side of the IDE:
Remote-WSL: Show Log
It opens a WSL terminal, which shows (between several infos) the IP Address that WSL is using. Adding this WSL IP to the xdebug.remote_host value, the only thing left to get Xdebug running correctly from your Docker container, inside your WSL2 environment (from WSL Remote VSCode extension), is adjusting your application path inside the launch.json file.
For that, clicking with the right-button mouse at the launch.json file tab, search and click on the "Copy path" option, and then paste it inside the pathMappings setting, like this sample (don´t forget to adjust the path removing the info relative to launch.json itself, it's for your application path!):
"pathMappings": {
"/application": "paste here the path you've copied"
}
Try it, for me worked like a charm. And if it work for you too, vote for my answer!
I have spent many days "ripping my hair".. I use docker.
add rule into firewall to allow traffic (taken/quoted from: https://github.com/microsoft/WSL/issues/4171#issuecomment-559961027
Go there for screenshots if this isn't clear enough)
In windows Start menu, type Firewall and choose Advanced settings, then Inbound Rules
select custom rule.
Click Next until you get to Protocol and Ports in the left menu
Select ICMPv4 as protocol type.
Select Next until you end up in the Name section, enter any name and click Finish.
If you now try pinging your host ip from wsl2, it should work as
expected.
For every other connection between your wsl2 and your host, you have
to allow the inbound rules for private and public networks or if they
don't exists manually create the rules for the corresponding UDP/TCP
port, but be aware that this might impact your security, if you use
your computer in public networks.
.vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9900,
"pathMappings": {
"/linux/path/in/docker":"${workspaceFolder}",
}
},
]
}
Dockerfile
RUN echo "zend_extension=/usr/lib/php/20190902/xdebug.so\n \
xdebug.remote_enable=on\n \
xdebug.remote_autostart=on \n \
xdebug.remote_connect_back=on\n \
# xdebug.remote_host=$HOST_IP\n \
# xdebug.remote_log_level=9\n \
# xdebug.remote_log=/var/www/mywebdir.com/xdebug.log \n \
xdebug.remote_port=9900" > /etc/php/7.4/mods-available/xdebug.ini;
EDIT:
After a while I started having problems again. Try these:
uncomment the logging lines above in dockerfile
try hard coding your windows ip address like 192.168.0.x
(uncomment xdebug.remote_host=... and comment out xdebug.remote_autostart=on)
My xdebug appeared to be connected but closed connection straight after because it had to be my windows ip. My understanding is that its the VSCode that responds to xdebug requests which runs in windows so the debugging packets need to get through out of WSL2.
try logging level 10. If you see that xdebug can't find a match for the breakpoints, check your webroot mapping in docker and pathMappings in vscode/launch.json
Check that you do have a breakpoint set (stupid but yeah)
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.
I have move from my Thinkpad laptop to HP Elitebook. I must set my development environment in my new laptop. After setup my Visual Studio Code and XAMPP in Windows 10 Pro 64 bit edition, I can't debug my PHP code.
I have properly installed Xdebug extension for Visual Studio Code, and make sure the php.ini correct. This is my setting for php.ini (I use portable XAMPP which is placed on E: drive):
zend_extension = "E:\xampp\php\ext\php_xdebug-2.4.1-5.4-vc9.dll"
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_log="E:\xampp\apache\logs\xdebug.log"
And my xdebug.log show information like this :
Log opened at 2018-10-27 05:56:45
I: Connecting to configured address/port: localhost:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///E:/xampp/htdocs/absen/index.php" language="PHP" xdebug:language_version="5.4.3-dev" protocol_version="1.0" appid="7112" idekey="william"><engine version="2.4.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2016 by Derick Rethans]]></copyright></init>
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
Log closed at 2018-10-27 05:56:45
But my Visual Studio Code won't stop at breakpoint.
I have reinstall my Visual Studio Code, XAMPP, and using another Xdebug version but it still doesn't work.
I have follow these links:
visual studio code PHP debugging not working
xdebug won't stop at breakpoint
xdebug breakpoint fail
Xdebug successfully connects to DBGP clients, but won't stop at breakpoints
None of these solutions work.
Finally i know the source of problem. The HP Elitebook have preinstalled program named HP Velocity, which used port 9000.
The issue is port 9000 from my host is bind to port 9000 of HP Velocity software. When HP Velocity service connect to the localhost xdebug server, logs say that connection is ok, but it is connected to HP Velocity.
I changed xdebug port to 9090 in php.ini and changed in launch.json on visual studio code. After that, my visual studio code work as usual and can stop at breakpoint.
Hope this help others :)
This is what fixed the same issue i was having,worth the shot if previous answers didn't help
php.ini
[XDebug]
zend_extension = "C:\xampp\php\ext\php_xdebug-3.0.2-8.0-vs16-x86_64.dll"
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_port = 9000
xdebug.client_host = "127.0.0.1"
xdebug.log = "C:\xampp\tmp\xdebug\xdebug.log"
xdebug.idekey = VSCODE
launch.json
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"type": "php",
"request": "launch",
"name": "Run using local PHP Interpreter",
"program": "${file}",
"runtimeExecutable": "C:\\xampp\\php\\php.exe"
}
]
In my case, the pathMappings was incorrect, and did not change the port
{
...
"configurations": [
{
...
"port": 9000,
"pathMappings": {
"/var/www/yourproject": "${workspaceFolder}/",
}
}
]
}
My Breakpoints is actually working if I check the "Everything" breakpoint
(It captured a suppressed exception, but VS code alerted that the file was no found)
In my case, I was trying to debug a php script on my local machine, so I had to realize that I had to debug the php script using the port which the Web Server is using (8080 in my case) rather than using the port set on the VS Code configuration (I use 9090).
For anyone who is stuck with this error, this is my configuration:
OS: Windows 10 64 bits
PHP 5.6 (32 bits TS)
Xdebug 2.5.5 (32 bits)
Apache 2.4 (32 bits)
Xdebug Helper installed on Google Chrome
1) httpd.conf
2) php.ini (XDebug section)
3) launch.json (VS Code configuration)
The reason might caused by the port of php xdebug.It works for me fine when I did this:
1.use php --ini to show php config file and change xdebug port to 9900:
xdebug.remote_port=9900
then restart your php
2.open vscode and change the port to the same number in launch.json:
"port": 9900
3.enjoy your debug
I am a novice programmer so this will probably sound dumb, but might be helpful to someone new to PHP and web servers like me.
I had the same issue with Xdebug skipping a break point. For me it turned out to be that I had a break point on an "echo" statement. Apparently that is not a valid line for using a break point. It started working once I moved the break point to a variable declaration.
I had same issue but after change port to 8000 in ubuntu it works for me.
Please note if you are using Xdebug version 3.xx you need to do the following:
Stop Apache server, then in php.ini add at the end of the file:
[XDebug]
xdebug.mode = debug
zend_extension="C:\xampp\php\ext\php_xdebug.dll"
After that, start Apache server agian.
Note that adding xdebug.start_with_request = yes will tell xdebug to initialise communication with an IDE for every request even though you might not debugging, which gives a warning in your IDE console state:
[Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-(
It's better to use a chrome extension to trigger the activation of xdebug using a cookie in your browser. See https://xdebug.org/docs/step_debug#browser-extensions for more information.
In vscode go to Run in your top menu, then Add configuration, this will open launch.json, add under configurations:
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003
},
Please note that port 9003 is different than your app port. I'm running my laravel app using: php artisan serve with port of 8000 and in my launch xdebug is 9003.
Re-run your debug in vscode and should be working.
I wish you the best in your bug-fighting war!
I saw the same issue, running ./vendor/bin/phpunit -c <config file> was causing all of my breakpoints to be disabled. I was only able to debug if I checked "Everything" and sorted through all the junk.
I updated the pathMappings in my launch.json file, and added a new launch configuration with a different pathMappings to work locally
{
"name": "PHP Unit Test XDebug",
"type": "php",
"request": "launch",
"port": 9001,
"log": true,
"externalConsole": false,
"pathMappings": {
"${workspaceFolder}": "${workspaceFolder}"
},
"ignore": []
},
I found this solution from this SO post, and this one here Debugging PHPUnit tests in VS Code?
Turns out the shell environment variable XDEBUG_MODE overrides the xdebug.mode setting in your php.ini, and I was setting the XDEBUG_MODE variable in my .zshrc file (likely a configuration from a previous project that I had long forgotten about).
In short, if xdebug isn't working and you've seemed to follow all of the instructions about setting up your IDE and php.ini file correctly, make sure you aren't inadvertently setting XDEBUG_MODE somewhere else.
I've installed Xdebug on my Vagrant server and the XdebugClient plugin for Sublime Text 3. When I start debugging, my page loads in the browser but nothing shows up in the context, watch or stack tabs. The xdebug.log file is also empty. The following are my settings:
php.ini
[CUSTOM]
error_reporting=1
display_errors=true
track_errors=1
[xdebug ]
zend_extension="/usr/lib/php5/20121212/xdebug.so"
xdebug.remote_connect_back=1
xdebug.default_enable=1
xdebug.remote_autostart=0
xdebug.idekey=sublime.xdebug
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=10.0.2.15
xdebug.remote_port=9001
xdebug.remote_log="/var/log/xdebug/xdebug.log"
xdebug.profiler_enable=1
xdebug.profiler_output_dir="/tmp/profiler"
xdebug.remote_mode=req
xdebug.ini
zend_extension="/usr/lib/php5/20121212/xdebug.so"
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=10.0.2.15
xdebug.remote_port=9001
xdebug.remote_log="/var/log/xdebug/xdebug.log"
.sublime_project
"settings": {
"xdebug": {
"url": "http://mysite.dev/",
"path_mapping": {"/vagrant/www/mysite/dist" : "/Users/iii/Documents/Dev/vagrant/www/mysite/dist"},
"super_globals": true,
"close_on_stop": true,
}
}
Xdebug.sublime-settings
{
"close_on_stop": true,
"pretty_output": true,
"launch_browser": true,
"debug": true,
"ide_key": "sublime.xdebug",
"port": 9001,
}
Can someone please tell me what is wrong here?
I was facing a similar problem with Vagrant/Sublime/Xdebug. I found that the latest version of Xdebug (2.6.0) doesn't work well with Sublime. Evidently, there's an XML formatting issue.
I found two things that both solved the problem:
Revert to Xdebug 2.5.5, or
set "super_globals": false, in your config.
(https://github.com/martomo/SublimeTextXdebug/issues/172)
ETA 24 Oct 2018:
In my case, the solutions above were not necessarily a fix, but just helped to avoid the real issue in some cases. The real fix appears to require a change to the Sublime Package: https://github.com/martomo/SublimeTextXdebug/issues/172#issuecomment-410478057
I ended up forking the SublimeTextXdebug (assuming this is the package you're using), patching it, and then replacing the package with the patched version. (There's a pull request in the main repository, but I don't think it's been pulled yet.)
Just in case someone else has the same problem. I was using Sublime 2 with Xdebug without any issues. I upgraded to Sublime 3 and was not able to get Xdebug to break. I went through various posts and tried various recommendations without success, until, I added the setting xdebug.remote_log="/var/log/xdebug/xdebug.log". No idea why, but once this was added, it started to work.