Xdebug Support: PHP debugging

That’s worrying. Can anyone else confirm this?
I’ll try and test it asap to see as well.

Yeah it’s a real bummer. I went back through and confirmed that the xdebug.ini file is where it should be and configured correctly, nothing changed in my VSCode config, but when I run debug mode the breakpoints are ignored and the only thing I did was update DevKinsta to the latest version after ignoring the update notices for quite some time. I’m totally baffled.

Hi everyone, I just wanted to drop a development update here:

Our devs have been using 2022 to integrate the most requested features into DevKinsta. At our current pace, built-in Xdebug support will be added during Q4 of 2022 along with other development-related features (like GIT integration). You can track our release progress here: https://community.kinsta.com/t/devkinsta-releases-minor/

I’m unsure of what change may have caused this workaround to no longer work, but I’ll make sure we notify this thread when DevKinsta officially supports Xdebug.

1 Like

Thanks for the update.

Q4 for xDebug support seems a little shabby tbh, considering debugging is a core developer task.
I would have thought you would give this a higher priority.

Yeah, appreciate the update. Glad to hear you are working on it, but I’m forced to agree that a Q4 rollout for this feature is lacking. It’s critical that we are able to debug, and now the work around no longer works, I’m sort of dead in the water when it comes to anything PHP related.

Hi @sonicviz and @jscotti, I agree that from a PHP development standpoint this is an important feature. I’m assuming when the Roadmap was finalized, basic web design needs were prioritized based on our surveys, interviews and forum engagement. I have notified our developers about this issue and spent a good deal of time figuring out how to get this work. Hopefully this works for everyone:

I based my setup on @sonicviz 's findings and this post. For some reason, using host.docker.internal no longer works and I had to use my ip address. I don’t know if that’s due to a DK change or a Docker one. I also changed the x.debug.idekey to “docker” but I’m not sure if that makes a big difference or not. Another setting I added was xdebug.discover_client_host=true.

Below is my working configuration for Windows 10, WSL2:

/etc/php/7.4.fpm/conf.d

zend_extension=xdebug.so
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_port = 9003
xdebug.idekey = "docker"
xdebug.client_host = <my ip address>
xdebug.log = /var/log/php/xdebug.log
xdebug.discover_client_host=true

Finding your IP address:

Mac:

ipconfig getifaddr en0

Windows (run command within WSL):

grep nameserver /etc/resolv.conf | cut -d ' ' -f2

Linux:

hostname -I | cut -d ' ' -f1

My launch.json still matches what has been shared.

Tested and working when viewing my WP Homepage:

So based on my many hours of troubleshooting, I think the issue that has popped up can be resolved by editing the xdebug config/restarting that container. Please let me know if this doesn’t work for you and I can put together a more in-depth guide. My goal here was to reproduce the issue and provide a solution while we wait for the DevKinsta update.

3 Likes

@Kevin Legend! That works perfectly, thanks so much for taking the time to figure out the work around, it’s very much appreciated!

1 Like

Thanks for taking the time to do that.

1 Like

Worked perfectly, thank you Kevin. I followed all the steps you outlined except changing my xdebug.idekey to docker. I left that set to VSCODE (my ide key) so it works with the cookie set by the xdebug helper chrome extension.

1 Like

I did use the great PHPstorm guide from @philippstracker when I validate xdebug connection to my https://mysite.local it is validated:

debugger validate screenshot

But PHPstorm receives no connections from xdebug, I’ve tried using xdebug.client_host = host.docker.internal, 172.172.0.1 and the WSL IP as suggested by @Kevin but no results. I tried changing port to 9001 or 9002, changing timeout of xdebug and nothing.
I have listening turned on in PHPstorm, chrome debug extension on, I set a breakpoint, refresh the page and no connection.

When I run xdebug_info() I get this output:

[Step Debug] Creating socket for '172.172.0.1:9003', poll success, but error: Operation now in progress (29).
[Step Debug] Could not connect to client host discovered through HTTP headers, connecting to configured address/port: 172.17.176.1:9003. :-|
[Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: 172.172.0.1:9003 (from REMOTE_ADDR HTTP header), 172.17.176.1:9003 (fallback through xdebug.client_host/xdebug.client_port) :-(

Any ideas on how to debug this debugger issue? I’m starting to lose my mind over this.

Hi @Greg36, welcome to DevKinsta! Unfortunately I’m not well versed with PhpStorm so I can’t give much advice here. I did try installing a trial version but couldn’t get it working consistently/was faced with a lot of configuration issues.

You could try getting xDebug to work with VSCode using the steps that have worked for others, perhaps that might help you track down the PhpStorm configuration issue.

Hopefully someone who has PhpStorm working with DevKinsta will chime in and share their configuration if the previous one no longer works.

1 Like

I’ve spent a few more hours on this topic, reinstalled everything including Docker Desktop, and finally, I found what the problem was - ports. But they were not blocked on WSL2 firewall but on the Windows firewall somehow. I run the following command and xdebug picked up breakpoint for host from IP in /etc/resolv.conf file in WSL. All running good now :slight_smile:
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

1 Like

Hi @Kevin are we still on track for Q4 to fully support XDebug?

(asking because ipconfig getifaddr en0 returns an external IP address and I travel a lot for work so this address will keep changing! :hot_face: Also probably explains why @Greg36 had to mess with firewall rules as the traffic is crossing interfaces)

Hi @jamesgreenblue, I believe xDebug support will be released with the next DK version (within weeks). It will probably need tweaking based on user feedback, though. We’re mainly working to make it easier to set up.

The IP address issue seems to be more due to something changing with Docker. I did originally recommend a way to automatically get the correct IP with a click to our Devs but I’m not sure if that will be in this release.

I’ll post an update in here once the feature is live!

2 Likes

I just switched to WSL2 from HyperV and had to set up XDebug again.
I followed Kevin’s WSL adapted guide Xdebug Support: PHP debugging - #56 by Kevin and it’s working fine (PHP 8.0) for me. Thanks Kevin!

I’m relieved! :joy:

PS: You can just use the IP address of the Ethernet vEthernet (WSL) you can see in the task manager.

1 Like

Hi Kevin,

This post is music to my ears. +1 from me on the need for xDebug to complete the local dev env.

Was this released? I see no mention of xDebug in the latest release line items.

Konstantin

Hi @Konstantin_Brazhnik,
This was about to be released with the current DK version, but I found a huge issue with it and we had to push back the release. We figured it was better to wait/do it right to avoid introducing performance issues.

It’s currently slated for the next release of DevKinsta before the end of the year. I’ll announce if it gets pushed back again, but I’m hopeful for a November/December release.

2 Likes

Kevin,

Happy New Year!

I’m excited to see xDebug in the release logs of the latest version of DevKinsta. Is there any documentation you can point me to about how to use it with VSCode? I’d been using Valet for a while and had no issue configuring PHP and VSCode to work with xDebug, but I’m not 100% sure how this translates to DevKinsta and the docker containers it runs.

Thank you!

Konstantin

Here’s how I got it working. From the wrench/site configurations option in DevKinsta I made sure “enable xdebug” was checked. In the PHP.ini editor I had the following lines:

xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.profiler_enable=1
xdebug.profiler_enable_trigger = 1
xdebug.discover_client_host = 1

You can verify this with a phpinfo(); output, but the config on my system was still using the classic port 9000, not the 9003 XDebug 3 supposedly moved to.

I have the PHP Debugv1.30.0 extension installed in VS Code. With that in place you’ll have the ‘Run and debug’ option on the left. Or press Shift-Command-D to open it. Let it create a launch.json file for you.

I removed everything but the “Listen for Xdebug” configuration; it’s not possible to launch a script for remote execution as far as I know so they were just cluttering up the options.

here’s what one of mine looks like, where my workspace is in the wordpress wp-content directory (I don’t want any visibility into the stock WP code or have searches find Automattic’s classes)

{
    // 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": {
                "/www/kinsta/public/devwebsite/wp-content/": "${workspaceRoot}/",
            }
        }
    ]
}

My experience has been that setting breakpoints visually can be iffy for triggering; I tend to add an xdebug() call in my code where I want it to halt. Just be careful you don’t leave them in when you push to Kinsta.

1 Like

Hi Don,

Thank you for sharing this information/test you did! :bowing_man: .
Hopefully that will be useful for other users as well! :+1: :smiley:

Cheers,
Agus