Skip to content

More sophisticated xdebug step-debugging support (trigger?) #3731

Closed
@nico-loeber

Description

@nico-loeber

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe

Me and a colleague evaluate the use of DDEV in our company (I use quite some time now for private purpose).
In our everyday work we use xdebug a lot to debug issues. Often we need to debug a single Request.
Also profiling is quite common to find bottlenecks in our code.

Currently DDEV just offers the options on and off, where on is debugging EVERY request and EVERY command on CLI.
The need to switch xDebug on and off via a command and the lack of possibility to debug a single request make it impossible to use DDEV for our everyday work in its current configuration.

Also profiling and tracing is not possible without manually editing the PHP configuration.

Another a bit annoying thing is, that you get spammed with Xdebug: [Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: host.docker.internal:9003 (through xdebug.client_host/xdebug.client_port) :-( as soon as xdebug is enabled and you run any php cli command.

Describe the solution you'd like

The common configuration for xDebug is to start on a trigger. This allows you to start debugging, profiling and tracing from your browser, or via your IDE when you start a cli debugging session.

Also it is possible to only debug the navigation event of the browsers which is especially usefull if you are working with an application where sub requests like files are only served by your application, as you get spammed with 50 debugging sessions or more.

The configuration used by my company for the use of xdebug looks like the following:

Xdebug 3 (PHP >= 7.2)

[xdebug]
xdebug.mode=develop,debug,profile,trace
xdebug.start_with_request=trigger

Xdebug 2 (PHP < 7.2)

[xdebug]
xdebug.remote_enable = ON
xdebug.remote_autostart = OFF
xdebug.remote_connect_back = ON
xdebug.coverage_enable = ON
xdebug.default_enable = ON
xdebug.remote_enable = ON
xdebug.profiler_enable = OFF
xdebug.profiler_enable_trigger = ON
xdebug.trace_enable_trigger = ON

I would like to use these configurations as a new default. Also the xdebug extension should be enabled by default, so you can profit from its development features like. Endless recursion detection, overloaded var_dump and other development features.

Of course this would be somehow a breaking change as people who are used to the behavior, that every request is debugged after enabling xdebug would now need to trigger the debugging session as shown below.

The ddev xdebug disable would be less important but might still be useful in case you would like to do performance comparisons as xDebug will affect your performance even without an active debugging session. This impact shouldn't be crucial for a development environment.

If this solution is accepted, I would like to create a pull request.

Describe alternatives you've considered

An alternative to changing the current behavior of ddev would be adding a new "xdebug mode" like ddev xdebug trigger or something like this. This would allow to introduce the new behavior in parallel of the current one.
But this would add up much complexity for the user as well as for implementing the pull request.

Additional context

Starting a debugging / profiling session from browser:
image

Starting a CLI debugging session from IDE:
image

Documentation on how to debug with PHPStorm:
https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html#integrationWithProduct

Edit: I did update the configuration samples to remove one unrelated option as well as correcting the php version relation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions