XDebug not working out of the box in VSCode

[kadamwhite]

Describe the bug
I would expect that after running composer server start --xdebug, I would be able to connect from VS Code. Following the instructions in this repository I am able to start the xdebug listener within VS Code, but trying to enable XDebug using a browser extension in either Firefox or Chrome fails to start (the icon does not turn Green, extension does not indicate it is listening) and no connection appears to be made between the browser, docker container, and editor.

I am wondering if this might be related to the autostart option; these are the php.ini settings after using --xdebug:

xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => host.docker.internal => host.docker.internal
xdebug.remote_log => no value => no value
xdebug.remote_log_level => 7 => 7
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200

To Reproduce
Steps to reproduce the behavior:

1. Set up new Altis environment
2. composer server start --xdebug
3. Install XDebug helper extension in Firefox or Chrome
4. Set up VS Code project as described in xdebug documentation for this server
5. Start debugging in VS Code
6. Try to enable debugging in your browser

Expected behavior
A clear and concise description of what you expected to happen.

1. Icon turns Green and browser extension indicates it is enabled
2. Setting a breakpoint in the editor and reloading the browser connects to xdebug and process stops at the designated breakpoint.

Actual behavior

1. Icon will never turn green / extension only indicates XDebug not listening
2. No action I can take seems to cause any PHP process information to be received by my editor

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• Browser: Chrome latest, FFox latest, Brave latest

[kadamwhite]

@roborourke Ugh, I thought I cracked it after reading about every VSCode + Docker post on the internet (this one was the winner, upon close reading) — I had this working ever so briefly, after setting

xdebug.default_enable = 1

(and changing the name of the Altis .ini file so that it loads last and doesn't get overwritten 😬)

But, in typical fashion I then did something that I didn't properly track, and now I can't recreate my success.

[kadamwhite]

Aha! I've now consistently gotten it to connect by toggling these two settings:

xdebug.default_enable = 1
xdebug.remote_connect_back = 1

[roborourke]

Nice work @kadamwhite - glad it wasn't the host name, that would've been a pain to solve.

I'll PR the ini file changes. I'm not sure default_enable should be needed still given there's remote_enable switched on but when you have to start the server with --xdebug explicitly it probably doesn't hurt. I was trying to make it so the server doesn't run too slowly by launching xdebug on every run if you're not running the debugger (it's ~2x slower) but I'm not sure it really made a difference.

[roborourke]

Digging a little deeper there were a few more things at play here:

• Setting the XDEBUG_SESSION cookie manually in PHP meant that the first run would not get caught by the debugger
• remote_connect_back tells XDebug to ignore the remote_host setting and rely on $_SERVER['REMOTE_ADDR'] or $_SERVER['HTTP_X_FORWARDED_FOR']

This tells me the problem is our default remote_host setting as I thought. Looking to see if there's a workaround for docker on linux or whether traefik can set the HTTP_X_FORWARDED_FOR header.

[kadamwhite]

I did wonder that about default_enable, but the value of better stack traces in the logs and errors is pretty big so since the whole thing's opt-in I'd suggest keeping it.

[roborourke]

I've found that there's a better way to default enable it using the XDEBUG_CONFIG environment variable. That means xdebug will always be on even for CLI commands which could be useful. Given you can switch easily between xdebug and no xdebug I think that's ok.

I found that technically you're supposed to be able to use the static IP 172.17.0.1 to connect to the host but it's not working on mac. When you set remote_connect_back to true it's making XDebug check $_SERVER['REMOTE_ADDR'] which gives that static IP address and that's why the setting makes it work for you.

It's really annoying that there isn't a global solution but I've made a PR that I'd appreciate a quick test of when you get a sec.

[roborourke]

Released in 4.0.1 and 3.0.6