Able to debug ONLY when running test - php

Using laravel/homestead vagrant box, VS Code, and PHP Debug extension, I can set breakpoints and step through code only when running a test via phpunit.
If I access the same resource via the browser, my breakpoints are never hit.
Based on the fact that I can debug when tests are running, I'm assuming that xdebug is working and configured properly.
My .env file:
APP_NAME=lms
APP_ENV=local
APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
APP_DEBUG=true
APP_URL=https://lms.test
My .env.testing file:
APP_NAME=lms
APP_ENV=testing
APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
APP_DEBUG=true
APP_URL=https://lms.test
PHP Debug config:
"configurations": [
{
"name": "Listen for XDebug on Homestead",
"type": "php",
"request": "launch",
"pathMappings": {
"/home/vagrant/code/MyProject": "C:\\Users\\lemon\\source\\vagrant\\MyProject"
},
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
app.php
'env' => env('APP_ENV', 'production'),
'debug' => env('APP_DEBUG', false),
netstat -rn | grep "^0.0.0.0 " | cut -d " " -f10
10.0.2.2
/etc/php/7.4/cli/conf.d/20-xdebug.ini
zend_extension=xdebug.so
xdebug.remote_enable = 1
xdebug.remote_autostart=1
xdebug.remote_host=10.0.2.2
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.max_nesting_level = 512
I've enabled xdebug logging. When I run the debugger during a test, the log is created and shows the expected entries. If I then delete the log file and make a GET from the browser, to the same controller as the test, no xdebug log is created.
Maybe some fresh eyes can identify the problem. Thanks!

On the command line, the xdebug.remote_connect_back=1 setting has no effect. In a web environment, it instructs Xdebug to make an IDE connection to the IP address from the HTTP headers. But if there is a NAT network in the way, as with Docker often is the case, the IP address from the HTTP header can not be connected to by Xdebug and hence the debug connection can not be made.
When you remove the xdebug.remote_connect_back=1 setting, Xdebug exclusively uses the xdebug.remote_host setting, which you already had set correctly yourself (to 10.0.2.2).
When using Docker, you can almost never use xdebug.remote_connect_back.

In desperation I deleted these lines from 20-xdebug.ini (and restarted the php service) and it worked.
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.max_nesting_level = 512
No idea why, but I hope this helps someone else.

Related

Listen for XDebug php in vscode with xampp

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.

My Xdebug is not working. Why isn't break points not working?

I have installed Xdebug with VS Code and Flywheel local and I am learning how to make themes. I have put a breakpoint in my index.php file. However, the said breakpoint is not working.
I am not getting any errors in my console. Nothing is happening in VS Code debug terminal when I load my site. It's just all blank. I have also installed PHP Debug extension in VS Code.
However, when I type in debug console anything I get this message - Cannot evaluate code without a connection.
What went wrong here?
My php.ini
[xdebug]
{{#if os.windows}}
zend_extension = php_xdebug.dll
{{else}}
zend_extension = {{extensions.xdebug}}
{{/if}}
xdebug.remote_enable=1
xdebug.remote_connect_back=Off
xdebug.remote_port="9000"
xdebug.profiler_enable=0
xdebug.remote_autostart = 1
xdebug.mode=debug
My 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": 9000,
"pathMappings": {
"C:/Users/ajayb/Local Sites/wordpress-theme-1/app/public": "${workspaceRoot}"
}
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
I have faced the same problem. Local by FlyWheel installs Xdebug 2.7 for PHP 7.3 and XDebug 3.x when using PHP 7.4. If you are using PHP 7.4 modify the php.ini file and replace the xdebug section with the following:
[Xdebug]
; Consider checking php_xdebug.dll file properties to get installed Xdebug version
zend_extension="D:\Programs\xammp\php\ext\php_xdebug.dll"
; Settings for Xdebug 2.x
xdebug.scream = 1
xdebug.remote_enable = 1
xdebug.show_local_vars = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
; Settings for Xdebug 3.x
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_port="9000" ; Default now is 9003
Even if you have XDebug's version 2.x.x, the default configuration is not enough.
You have to use the following for Xdebug v2.x.x:
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_port = 9000
Yeap, as it was mentioned in a comment the main reason is https://xdebug.org/docs/upgrade_guide
I had the same issue with PHPStorm & Flywheel Local app v6+.
I set PHP 7.4.1 in Local and found in ~/projects/project-name/conf/php/php.ini.hbs next v2 options:
xdebug.remote_enable=1
xdebug.remote_connect_back=Off
xdebug.remote_port="9000"
xdebug.profiler_enable=0
But when I checked var_dump(phpversion('xdebug')); it ouptuted XDebug 3. It worked for me with v3 options:
xdebug.mode=debug
xdebug.start_with_request=trigger
xdebug.client_port="9003"
xdebug.discover_client_host=0
My problem was that i wasnt changing the php.ini in the right place.
There is a general conf\php folder and there are version specific ones.
Changing php.ini xdebug settings in conf\php solved it.
Also i put the full path in the pathmappings(launch.json) like so:
"pathMappings": {
"C:\\Users\\Test\\Local Sites\\localtest\\app\\public": "${workspaceFolder}",
}

Issues when Debugging PHP in VSCode using Docker and WSL2

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.

Debugging PHP in Visual Studio Code

I am trying to debug a wamp-based website using VSC. When I start the debugger using the configuration Listen for XDebug, the Debug control panel opens. The Step Over, Step Into and Step Out controls are not active (I assume they become active when the program starts?). I have two breakpoints set up.
This is the launch.json file that VSC created for PHP:
"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
}
]
This is the XDebug config in php.ini
; XDEBUG Extension
[xdebug]
zend_extension ="c:/wamp64/bin/php/php5.6.31/zend_ext/php_xdebug-2.5.5-5.6-
vc11-x86_64.dll"
xdebug.remote_enable = off
xdebug.profiler_enable = off
xdebug.profiler_enable_trigger = off
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir ="c:/wamp64/tmp"
xdebug.show_local_vars=0
I changed these lines as per XDebug extension docs in VSC
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
When I start(submit a form), the code executes, but the VSC debugger doesn't engage, execution doesn't stop at the breakpoints, data is inserted in some tables. Am I missing some configuration so that the debugger does something, stops at the breakpoints? The VSC docs here
https://code.visualstudio.com/docs/editor/debugging
only highlight debugging with Node.js debugger. Appreciate any guidance on this.
I needed to ask for more info through comment section but I did not have enough reputation to do so :)
I suspect the PHP.ini file that you have modified is not the correct one. As you mentioned, you're dealing with WAMP, therefore there must be at least two PHP.ini files:
Command Line Interface (CLI)
Apache.
You should have modified the second one since you're running Apache.
I'm not quite sure about the exact path to those two files. I hope this could help.
How to know which PHP.ini is loaded?
Run phpinfo(); in your script in VSCode. It brings up your PHP configuration info. Look for: Loaded Configuration File.

Visual Studio Code - Xdebug won't work

In Visual Studio Code (1.9.1) (mac) i have setup the php-debug plugin.
In the debug screen i start 'listen for Xdebug'.
After this i open the index.php on my XAMPP server (local).
But nothing happens.
the blue bar at the bottom of the screen turns orange.
the step over, step into and step out buttons are greyed out.
Also the following error message occurs at the watched variables:
cannot evaluate code without an connection
I try to use breakpoints on the following code:
<?php
$i = 0;
do {
$i++;
if (!($i % 1)) {
echo('<p>$i = ' . $i . '</p>');
}
}
while ($i < 100);
?>
I am using XAMPP and in my php.ini file i use port 9000 for Xdebug.
zend_extension="/usr/local/Cellar/php71-xdebug/2.5.0/xdebug.so"
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote.port=9000
I installed Xdebug using homebrew.
Here is my php info:
phpinfo.htm
Xdebug wizard tells me Xdebug is installed correctly.
my launch.json file looks like this:
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
"log": true
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
Would anyone know what i am doing wrong?
After setting the xdebug.remote_connect_back = 1 in the ini file
as n00dl3 suggested debugging most of the time works, but once in a while i get the following
error in the debug console:
<- threadEvent
ThreadEvent {
seq: 0,
type: 'event',
event: 'thread',
body: { reason: 'exited', threadId: 1 } }
I encountered this problem as well, not with the same environment (NGINX server + php-fpm) but the same symptoms. It turned out to be caused by my xdebug configuration.
How I managed to diagnose it : by writing a simple PHP script for test just like OP did :
<?php
xdebug_info();
By browsing to it, I got a bunch of info on my setup, including :
xdebug.client_host => localhost
xdebug.client_port => 9003
whereas my xdebug was listening on port 9900 (default being 9000).
Steps to fix : just add the following lines to your php.ini or xdebug.ini (wherever the rest of your xdebug configuration lies) :
# This should match your xdebug.remote_host
xdebug.client_host=localhost
# This should match your xdebug.remote_port
xdebug.client_port=9900
xdebug.mode=debug
Then rerun a debug session in VScode, add some breakpoints, and re-browse to your script : my VScode window popped up, the execution was paused on the breakpoint and the variables where accessible in the debug pannel just like expected.
EDIT : don't forget to also :
add xdebug.mode=debug to your php.ini
restart webserver and php-fpm services.
It seemed the server root needed to be set
in the launch.json with localSourceRoot like this:
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
"log": true,
"localSourceRoot": "http://127.0.0.1/public_html/"
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
Now breakpoints are working like they should.
In my case, these two lines were missing from the php.ini file.
xdebug.mode = debug
xdebug.start_with_request = yes
Check xdebug.client_port
in page xdebug_info(); or phpinfo();
Config same port in launch.json of vscode
I just had this problem too.
Somehow, someday, without realizing it, I got version 3 of xdebug installed, and a lot of conf param name changed , see this SO question
So verifying the xdebug version with phpinfo for example can be worth a shot.
I am working with VSCODE devcontainer and I fix with the config below:
My launch.json for VSCODE
{
"version": "0.2.0",
"configurations": [
{
"name": "Xdebug",
"type": "php",
"request": "launch",
"port": 9003
}
]
}
I use Dockerfile with a RUN below to install xdebug:
RUN pecl install xdebug && docker-php-ext-enable xdebug
I find my xdebug config file in /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
I edit the file as below:
zend_extension=xdebug
[xdebug]
xdebug.mode=debug
xdebug.client_host=host.docker.internal
xdebug.start_with_request=yes
xdebug.idekey=VSCODE
Or you can add it in Dockfile like below:
RUN echo ' \n[xdebug] \n\
xdebug.client_host=host.docker.internal \n\
xdebug.mode=debug \n\
xdebug.start_with_request=yes \n\
xdebug.idekey="VSCODE" \n\
\n' >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
mode This setting controls which Xdebug features are enabled. We’ve set develop to enable development aids, such as getting better error messages, and debug to enable step debugging.
client_host This setting tells Xdebug the IP address or hostname of the machine that is running your text editor or IDE.
start_with_request This setting determines whether a function trace, garbage collection statistics, profiling, or step debugging are activated at the start of a PHP request. Setting it to yes instructs Xdebug to always initiate a debugging session.

Categories