Hi all, I want just to share my steps to make this working with PhPStorm and Linux Mint
first, install xdebug
docker exec devkinsta_fpm bash -c 'apt-get update;apt-get -y install php7.0-xdebug php7.1-xdebug php7.2-xdebug php7.3-xdebug php7.4-xdebug php8.0-xdebug'
Then I added these lines on my xdebug.ini
zend_extension=xdebug.so
xdebug.mode=develop,debug
xdebug.client_host=172.19.0.1
xdebug.client_port=9003
and then I restart the container
docker exec -it devkinsta_fpm bash
Thank you all!
I really hope to see XDebug in DevKinsta soon without the manual setup/configuration.
Iām trying to figure out how to get this all set up. Iām having no luck. I added the following the xdebug.ini
zend_extension=xdebug.so
xdebug.mode=develop,debug
xdebug.client_host=172.19.0.1
xdebug.client_port=9003
xdebug.start_with_request = yes
xdebug.idekey = PHPSTORM
xdebug.log = /var/log/php/xdebug.log
I canāt get anything to work. Is there a correlating setting I am missing? I have the xdebug extension for chrome installed and running. I found the settings for it and it is looking for the PHPSTORM IDE key. I have PHPStorm listening and I even used the built in validation tool and it all checked out. So Iām not sure why my breakpoints arenāt catching.
Any help is much appreciated. Thank you.
What am I missing here?
Hi @robruiz - did you see the guide Iāve posted here?
Iām not familiar with the dialog in your screenshot. Iāve configured Xdebug via āPhpStorm > Preferencesā¦ > PHP > Debugā
Also, I do not use an IDE key, as I enable or disable debugging via the Chrome extension. Generally, the IDE key caused problems for me in the past, so I never use it. I always enable or disable Xdebug in the whole environment instead of using IDE keys/session ids.
Aside from that, I recommend clicking the āValidateā link in your āPre-configurationā section. Possibly, you will get some additional tips from PhpStorm on whatās failing.
I did not stumble upon this. Thank you so much for pointing it out. Iām gonna run through this and give it a try. Thanks!
Any updates on this? Itās been a year and still nothing.
I got a notice that port 9003 was already in use. I didnāt want to debug it, so I just changed it to 9999 in xdebug.ini and launch.json. And it worked! Awesome! Thanks!
@sonicviz guide worked great until I recently updated to the latest DevKinsta and now it no longer works. Breakpoints are entirely ignored. Itās unbelievable that something this basic has not been addressed by the devs after this long. Wordpress is based on PHP and yet debugging PHP is somehow not supported without tons of effort, and it wonāt last if you keep the app updated, apparently. Word to the wise if you are finding this page because youāre having the same issues we all did; if you get it to work DO NOT UPDATE DevKinsta until they announce official support for this basic feature.
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.
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.
@Kevin Legend! That works perfectly, thanks so much for taking the time to figure out the work around, itās very much appreciated!
Thanks for taking the time to do that.
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.
I did use the great PHPstorm guide from @philippstracker when I validate xdebug connection to my https://mysite.local it is validated:
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.
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 
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow