4

I set up a Laravel dev environment using Docker - nginx:stable-alpine, php:8.0-fpm-alpine and mysql:5.7.32. I install Xdebug from my php.dockerfile:

RUN apk --no-cache add pcre-dev ${PHPIZE_DEPS} \ 
&& pecl install xdebug \
&& docker-php-ext-enable xdebug \
&& apk del pcre-dev ${PHPIZE_DEPS}

And include two volumes in docker-compose to point php to xdebug.ini and error_reporting.ini:

    volumes:
  - .:/var/www/html
  - ../docker/php/conf.d/xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
  - ../docker/php/conf.d/error_reporting.ini:/usr/local/etc/php/conf.d/error_reporting.ini

My xdebug.ini looks like this:

zend_extension=xdebug

[xdebug]
xdebug.mode=develop,debug,trace,profile,coverage
xdebug.start_with_request = yes
xdebug.discover_client_host = 0
xdebug.remote_connect_back = 1 
xdebug.client_port = 9003
xdebug.remote_host='host.docker.internal'
xdebug.idekey=VSCODE

When I return phpinfo() I can see that everything looks set up correctly, showing xdebug version 3.0.4 is installed, but when I set a breakpoint in VSCode and run the debugger its not hitting it.

My launch.json looks like this:

{
"version": "0.2.0",
"configurations": [
    {
        "name": "XDebug Docker",
        "type": "php",
        "request": "launch",
        "port": 9003,
        "pathMappings": {
            "/var/www/html": "${workspaceFolder}/src",
        }
    },
]

}

My folder structure looks like this:

- Project
-- /docker
--   nginx.dockerfile
--   php.dockerfile
--- /nginx
---  /certs
---  default.conf
--- /php
---- /conf.d
----   error_reporting.ini
----   xdebug.ini
-- /src (the laravel app)
Cody
  • 133
  • 7
  • Are you running the debugger or the script? Have you tried setting a breakpoint and running the script (via CLI or browser)? – Sam020 Aug 30 '21 at 13:44
  • The idea is that you run (the play-button) the debugger which then watches for breakpoints/errors when you run the script. – Sam020 Aug 30 '21 at 13:46
  • I'm running the debugger through vscode, the "Run and Debug" icon on the left, selecting the "XDebug Docker" profile and clicking the play icon next to it. – Cody Aug 30 '21 at 13:50
  • That is correct. And after you've done that, you should run the PHP-application/script you are testing. When an error/breakpoint occurs, it will be shown in VSCode with tools and context for analysis. – Sam020 Aug 30 '21 at 13:53
  • This is what I am doing, and the breakpoint is not being hit. – Cody Aug 30 '21 at 13:56
  • 1
    `xdebug.remote_connect_back = 1` no longer exists in Xdebug 3. `xdebug.remote_host='host.docker.internal'` ← remove the single quotes. What does `xdebug_info();` in a script that you're trying to debug show? On Linux, `host.docker.internal` doesn't work without hacks → https://www.youtube.com/watch?v=ZIGdBSD6zvU @ 1:10 – Derick Aug 30 '21 at 13:58
  • 1
    I second @Derick his suggestion about `xdebug_info();`. Host.docker.internal (without quotes) works out-of-the-box for me on macOS. – Sam020 Aug 30 '21 at 14:14
  • I removed the quotes from host.docker.internal, rebuilt and ran xdebug_info(). In the Diagnostic Log section, it shows: ⚠️ [Step Debug] Creating socket for 'localhost:9003', poll success, but error: Operation in progress (29). ⚠️ [Step Debug] Creating socket for 'localhost:9003', connect: Address not available. [Step Debug] Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-( – Cody Aug 30 '21 at 14:27
  • 1
    Ah, that's correct. Because Xdebug 3 has it as `xdebug.client_host` - it still said `localhost` for you, as that's the default value.: https://xdebug.org/docs/upgrade_guide#changed-xdebug.remote_host – Derick Aug 30 '21 at 14:34
  • @Derick - looks changing to xdebug.client_host corrected it! Thank you, sir! – Cody Aug 30 '21 at 14:45
  • 1
    I've added that as a proper answer too then, so others can find it. – Derick Aug 30 '21 at 14:49

1 Answers1

4

Xdebug 3 has changed the names of settings. Instead of xdebug.remote_host, you need to use xdebug.client_host, as per the upgrade guide: https://xdebug.org/docs/upgrade_guide#changed-xdebug.remote_host

xdebug.remote_connect_back has also been renamed in favour of xdebug.discover_client_host, but when using Xdebug with Docker, you should leave that set to 0.

Derick
  • 35,169
  • 5
  • 76
  • 99
  • When I run xdebug_info I get two warnings, should I be concerned about these? ⚠️ [Step Debug] Creating socket for '172.31.0.1:9003', poll success, but error: Operation in progress (29). ⚠️ [Step Debug] Could not connect to client host discovered through HTTP headers, connecting to configured address/port: host.docker.internal:9003. :-| – Cody Aug 30 '21 at 14:57
  • Not really, but it hints at that you have `xdebug.discover_client_host` set to `1`, which you shouldn't do. – Derick Aug 30 '21 at 15:47
  • `xdebug.discover_client_host` is set to `0` – see `xdebug.ini` above. – Cody Aug 30 '21 at 17:07
  • I just won't worry about it, unless it causes issues somehow. Thanks. – Cody Aug 30 '21 at 17:08