[wp-trac] [WordPress Trac] #63979: WordPress Core setup does not configure XDebug properly

[WordPress Trac]

#63979: WordPress Core setup does not configure XDebug properly
------------------------------+------------------------
 Reporter:  jdeep             |       Owner:  SirLouen
     Type:  defect (bug)      |      Status:  reviewing
 Priority:  normal            |   Milestone:  6.9.1
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  commit            |     Focuses:
------------------------------+------------------------

Comment (by westonruter):

 Xdebug is working for me on a Mac, with and without this patch. Gemini
 explained to me why it works on a Mac without the patch but it fails on
 Windows with WSL:

 > '''Windows (WSL2):''' WSL2 runs as a distinct, lightweight Linux Virtual
 Machine. It has its own IP address and its own "Loopback" interface
 (`127.0.0.1`). When Xdebug tries to connect to `localhost`, it connects to
 the container's own internal network. Since PhpStorm isn't installed
 inside the container, the connection fails.
 >
 > '''The Fix:''' `host.docker.internal` is a special DNS name Docker adds
 to the container specifically to resolve to the Host's internal IP
 address.
 >
 > '''macOS:''' While also a VM, Docker Desktop for Mac binds ports and
 handles networking differently to make it feel more "native." However,
 relying on localhost here is technically "incorrect" for Docker and often
 breaks if you change network modes.

 Moreover, it suggests an additional "universal" fix:

 > Instead of forcing your colleague to change their config to
 `host.docker.internal` and you keeping `localhost`, you should both use
 the Discovery mode. This works on Mac, Windows, and Linux without changing
 a single line of config.
 >
 > Change your php.ini (or Xdebug config) to:
 > {{{
 > # 1. Turn on Discovery
 > xdebug.discover_client_host = true
 >
 > # 2. Set client_host as a fallback only (can be left as localhost or
 host.docker.internal)
 > xdebug.client_host = host.docker.internal
 > }}}
 >
 > '''Why this is better:''' When `discover_client_host` is `true`, Xdebug
 ignores the `client_host` setting. Instead, it looks at the incoming HTTP
 request headers (like `$_SERVER['REMOTE_ADDR']`) to find the IP address of
 the computer that sent the request (your computer). It then connects back
 to that IP automatically.
 >
 > '''Summary for your Windows Colleague'''
 > Because WSL2 is a real Linux VM, localhost points to the Linux VM, not
 Windows. You have to use host.docker.internal so the container knows how
 to route out of the VM and talk to PhpStorm on Windows.

 In reading the [https://xdebug.org/docs/all_settings#discover_client_host
 Xdebug docs] about `discover_client_host`, it seems to make sense. Do note
 there is a warning, however:

 > Please note that there is no filter available, and anybody who can
 connect to the webserver will then be able to start a debugging session,
 even if their address does not match xdebug.client_host.

 But since the wordpress-develop environment is local, there doesn't seem
 to be any concern here.

 So should the patch be amended to include
 `xdebug.discover_client_host=true`?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63979#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform