This is the latest edition of DDEV Live Contributor Training.

We'll look into the intricacies of Xdebug in general and with DDEV's support specifically.

General outline:

How Xdebug works (network protocol, php makes the connection, IDE is listener)
Troubleshooting xdebug tries to explain this
The normal technique with DDEV is to start the IDE listening and `ddev xdebug on`
vscode extension does all this for you
You can set up xdebug several other ways, see xdebug.org. But DDEV’s base technique has been accessible and usable and reliable for many, many people.
Because it’s a network protocol, anything that gets in the way of TCP can break it. This includes name resolution, firewalls, and DDEV’s own mapping of `host.docker.internal` to a proper IP address.
If you’re having trouble, go through the troubleshooting instructions carefully, step-by-step
DDEV tries to sort out network difficulties, but there are specific situations that can require manual intervention
On WSL2, it’s possible to run your IDE inside linux (using the Linux version of vscode or PhpStorm). In that case, you need to `ddev config global --xdebug-ide-location=wsl2`
On WSL2 and with the IDE on Windows there are times that DDEV just can’t figure out what the right IP address using all the available tools. In this case, if you can figure it out, you can use `ddev config global --xdebug-ide-location=`
If you’re running your IDE on something that is network-reachable from inside the web container and it is not the normal host location, you can set an explicit `xdebug-ide-location` to reach it.
Send money to Derek
First thing in any language is learning to debug