9

I used to have the following configuration with Xdebug 2:

xdebug.default_enable=1

Xdebug did not slow down execution when no debug client was listening but when I needed to debug something then I only had to enable the listening in PhpStorm and refresh the page. No browser extension was needed for this. The same applied for debugging CLI applications, it just worked.

I tried to achieve the same with Xdebug 3 with the following configuration:

xdebug.mode=debug
xdebug.start_start_with_request=yes

It works the same BUT every time when I disable debug listening in PhpStorm and run a CLI command I get the following message with error severity:

Xdebug: [Step Debug] Could not connect to debugging client. Tried: 172.17.0.1:9003 (through xdebug.client_host/xdebug.client_port) :-(

This is something that I could live with but it also makes PHPUnit tests fails beStrictAboutOutputDuringTests="true" is enabled.

The upgrade guide suggest to use xdebug.module=develop if I used xdebug.default_enable=1 but that is not a valid replacement.

Completely silencing ALL Xdebug logs or even disabling error reporting in PHP suggested by this comment looks a dirty hack to me with possible drawbacks instead of a valid solution.

How can I keep the expected behavior without this message?

LazyOne
  • 158,824
  • 45
  • 388
  • 391
mxr576
  • 141
  • 1
  • 4
  • 1) Yes, you need `xdebug.mode=debug` for debugging (you can also combine multiple values if you need it, e.g. `xdebug.mode=debug,develop` but currently PhpStorm does not understand that if you are using their optional Validation tool). – LazyOne Jan 08 '21 at 11:32
  • 2) *"How can I keep the expected behavior without this message?"* What's your `error_log` config value? Sounds like it's empty. If you point it to the valid file (e.g. `/var/log/php_error.log`) then such error message will be sent there (Xdebug uses standard PHP error logging; PHP (yes, PHP) prints it in your std output because the value is not configured and and gives you a chance to see it). – LazyOne Jan 08 '21 at 11:34
  • If properly configuring PHP's error log is a "dirty hack" for you or you do not want to configure that at all for whatever reason ... then do not use `xdebug.start_start_with_request=yes` and tell Xdebug that it needs to debug this script when needed in some another way (e.g. pass such param to PHP executable when running that script, have `xdebug_break();` in your PHP code, set up Xdebug ENV variable etc -- check Xdebug docs) – LazyOne Jan 08 '21 at 12:39
  • Thanks for the ideas, I am usually using wodby/php for development and this is the default configuration: https://github.com/wodby/php/blob/4.18.6/7/templates/docker-php-7.3.ini.tmpl#L26 Currently, the error_log configuration cannot be overridden via env vars in this image, so I opened an issue: https://github.com/wodby/php/issues/134 – mxr576 Jan 09 '21 at 14:50
  • 1) What about `.user.ini` file? -- https://www.php.net/manual/en/configuration.file.per-user.php The value of `error_log` can be changed *anywhere* (as it's PHP_INI_ALL) even during runtime using [`ini_set()`](https://www.php.net/manual/en/function.ini-set.php) 2) `XDEBUG_CONFIG` -- when this ENV var is present it acts sort of "start debugging" trigger flag already (not documented behaviour). – LazyOne Jan 09 '21 at 15:30
  • In the end, I used the XDEBUG_CONFIG: "log_level=0" environment variable for overriding xDebug's default behavior. – mxr576 Jan 11 '21 at 09:42
  • 2
    Please consider making your solution as an answer (you can accept your own answers) -- why you have chosen that option, why other options were not acceptable/usable for you (no control over them etc). Having some details always helps. This will help a lot other users in a similar situation and having an answer will make it more visible/useful. Thanks. – LazyOne Jan 11 '21 at 09:57

2 Answers2

13

Xdebug 3 now warns when it is instructed (through xdebug.start_with_request=1 or with a COOKIE, or GET parameter) and it can not connect to your IDE. Previously a lot of people were having issue with getting Xdebug to work, and having this warning is really useful to them to point out that something is going wrong.

The correct way of not showing an error message is to not instruct Xdebug to make a connection to your IDE at all.

I recommend to use xdebug.start_with_request=trigger and then use either a browser extension as a trigger (https://xdebug.org/docs/step_debug#browser-extensions), or by exporting export XDEBUG_SESSION=yourname on the command line.

Setting xdebug.log_level=0 means you hide all warnings and errors, which makes it impossible to debug anything. Don't do that.

Derick
  • 35,169
  • 5
  • 76
  • 99
  • 1
    Hi Derik, can you check my answer above? Thank you https://stackoverflow.com/a/65725090/3822351 (It was too long for a comment) – mxr576 Feb 02 '21 at 17:59
  • Hi Derick. I have set `xdebug.start_with_request=trigger` but my CLI still tries to connect every time and I get this warning everytime. I even configured `xdebug.trigger_value=PHPIDE`. Everything looks great in `xdebug_info()` but I still get the warning. Is it working as excpected ? – Growiel Nov 26 '21 at 08:51
  • 1
    Derick, it would be immensely appreciated to know an answer to the question @mxr576 asked. Quoting him "*We had a workflow in our company with xDebug 2 that did not require any additional browser extension or environment variable (see above), just the listening to xDebug connection had to be enabled in the IDE and magic... **Are you suggesting that this workflow is not supported anymore in xDebug 3?***" – Samuel Gfeller Apr 26 '22 at 11:18
  • It was export XDEBUG_SESSION=yourname that did it for me – Max Apr 12 '23 at 22:01
5

thanks for sharing your thoughts about this Derick.

Setting xdebug.log_level=0 means you hide all warnings and errors, which makes it impossible to debug anything. Don't do that.

I do not want to do this at all, but currently I do not see an another way around to keep the old behavior as I explained in the issue description.

Previously a lot of people were having issue with getting Xdebug to work, and having this warning is really useful to them to point out that something is going wrong.

I totally understand the motivation behind this new behavior and I also see it could be useful for many people. Although, the fact that this warning cannot be suppressed can cause problems to those who knows what they are doing.

Well, "what they are doing" is maybe an inappropriate phrase, what they want is probably better...

We had a workflow in our company with xDebug 2 that did not require any additional browser extension or environment variable (see above), just the listening to xDebug connection had to be enabled in the IDE and magic... It is a documented solutation and our Docker based developer stack made sure that xDebug worked OOTB for every developer. (Again, without any additional dependency)

Are you suggesting that this workflow is not supported anymore in xDebug 3?

Is there any chance to add a new configuration to xDebug 3 that would allow suppressing only these new warnings and enabling "expert mode"?

mxr576
  • 141
  • 1
  • 4
  • 1
    Have you found a better workaround in the meantime maybe with the new env variables `PHP_XDEBUG_LOG` and `PHP_XDEBUG_LOG_LEVEL` they added ? Because `xdebug.log_level=0` doesn't display the errors when ran with cli (phpunit) but the process doesn't finish after tests are done. Tests may finish in 120ms and display the results but the process is still under execution (and my ide thinks its still testing which is annoying) for more than 10 seconds. Note: when log_level is enabled, it displays the error you quoted in the question like 10 times each second. – Samuel Gfeller Mar 30 '21 at 13:12