Xdebug: [Step Debug] Could not connect to debugging client - flooding logs

Issue Summary

Xdebug: [Step Debug] Could not connect to debugging client. Tried: 127.0.0.1:9000 (from HTTP_X_FORWARDED_FOR HTTP header), localhost:9000 (fallback through xdebug.client_host/xdebug.client_port)

This error is non-stop in the log

Same issue as reported here but never got a real answer: Xdebug: [Step Debug] Could not connect to debugging client

Troubleshooting Questions

Making the below changes to php.ini.hbs file (Install PHP 8 - #8 by afragen) does not have any effect. I edited the file, reload pages on the site, and still get the error every page load.

xdebug.mode=debug
xdebug.client_port=9003
xdebug.start_with_request=trigger
xdebug.discover_client_host=yes

Replication

  • Apply PHP 8.0.0 to any of the projects
  • Access any of the site pages
  • The PHP error log gets flooded with the recurring error

System Details

  • Local 6.5.2 + 6204
  • macOs Ventura Version 13.0.1

The same error here with the same environment. I’ve tried different xdebug configurations but except for turning off the logs (which is something we don’t want) the warnings kept coming.

Also experiencing this with any version of PHP greater than 7.3.5.

1 Like

You must add the following to eliminate those messages.

xdebug.log_level=0

The other solution is to turn off xDebug for the site in Local 6.6.0 and turn on only when needed and your debugger is active.

3 Likes

Thanks for replying… but where do I put that line of code?

Honestly the simplest solution is to use Local 6.6.0 and turn off xDebug when you aren’t using it.

The file is the php.ini.hbs file and on a Mac it’s located inside the Local.app package contents. If that sounds unfamiliar I really recommend the first method. Besides this method would need to be re-done at every app update.

Having the same issue here

Same issue here… sure would be nice to get this fixed since it’s such a PITA to fix every localwp update, php update, php version change, etc…

BTW, setting xdebug.log_level=0 only worked for me after changing it in the site folder as well /site_name_/app/conf/php/php.ini.hbs

But I also updated it in each of the 3 PHP versions (7.4, 8.0, 8.1) below that. AND also updated php.ini.hbs under Application_Support. And restarted the site what seemed like 15 times since php.ini changes I presume require that to take effect. So who knows what really fixed this.

1 Like

Hi @jb510 and @radiantpunch! Did you catch @afragen’s suggestion here?

Yes, but 100% of the time I’m running a site locally it’s because I’m writing code and debugging that code. There is little reason to ever run a site locally without xdebug on.

2 Likes

Yes, exactly. I always need debug on when I’m running a site locally.

Hi all - thanks for sharing the perspective here! This is good context and helps us understand how users are interacting with Xdebug.

In looking at the code, as far as I can tell we’ve always used a default log_level of 7, which is Information - Xdebug: Documentation » All settings

The thinking was that the point of using Xdebug was to see verbose logging while you were troubleshooting.

I will bring this up with the engineers to see if making a change to the default log_level makes sense, but I wonder if the real solution isn’t some sort of Xdebug configuration panel within Local that makes editing these values easier. Ideally, users shouldn’t have to manually edit php.ini files to achieve this, or worry about upgrades wiping changes. We could also explore new site defaults, similar to how Local approaches environments, admin e-mail, domain suffix, etc., that would allow users to configure how they expect Xdebug to be configured on a site.

I’m open to any thoughts this group has, and I appreciate the discussion so far!

1 Like

Unfortunately the only way to remove that seems to be to set the log level to 0. This stops all xDebug logging.

Might be worthwhile to somehow add a setting for xDebug logging. If checked, set to level 7, if unchecked set to level 0.

@Nick-B perhaps the simplest solution is to set the log level = 0 when the xDebug switch is toggled on. I’m pretty sure the vast majority of us aren’t trying to debug xDebug itself.

added this code to the php.ini file and it worked for me. filepath for others: conf->php->php.ini.hbs

1 Like

The log level here is only for debugging xDebug itself, not for debugging PHP.

adding the single line to the php.ini.hbs file does work.

{{#if xdebugEnabled}}
xdebug.mode=debug,develop
xdebug.log_level=0
{{else}}
xdebug.mode=off
{{/if}}
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.discover_client_host=yes

It would be a nice addition and pretty simple to do.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Sorry that this has fallen through the cracks a bit. I’ve moved this to the “Bugs” category and re-opened it so that we can keep the community in the loop.

I don’t have an ETA when this will be released, but we’ve been making improvements to our CI/CD pipeline to make the compiling and releasing of these lightning services more streamlined.

3 Likes

So this is still a problem. I’m just a simple site builder forced to use Local because Flywheel will only talk to me about errors if I can reproduce them on Local. Do these thousands of messages mean that there are thousands of bugs that are not getting logged properly? How can I just get the normal debug.log like WordPress creates by default when WP_DEBUG is enabled? I do not want to use/learn “Xdebug”.