Developing software in the Real World

My Xdebug configuration

With the release of Xdebug 2.3, I have updated my xdebug php.ini settings, so it seems sensible to write them down where I won’t lose them!

The new-for-2.3 features which prompted this are xdebug.overload_var_dump, which Derick has written about and xdebug.halt_level which I have previously written about. I find both of these very useful.

This is my current php.ini configuration:

; Xdebug settings

; var_dump() displays everything, including filename and line number
xdebug.overload_var_dump        = 2
xdebug.var_display_max_children = -1
xdebug.var_display_max_data     = -1
xdebug.var_display_max_depth    = -1

; don't supress errors
xdebug.scream = 1

; stop if there's a warning/notice
xdebug.halt_level = E_WARNING|E_NOTICE|E_USER_WARNING|E_USER_NOTICE

; remote debugging
xdebug.remote_enable       = 1
xdebug.remote_connect_back = 1
xdebug.remote_port         = 9000

; profiling is triggered via browser extension
xdebug.profiler_enable         = 0
xdebug.profiler_enable_trigger = 1

For every other setting, I’ve found that the default is fine.

I control html_errors within my app so that it’s set to 1 when the app is rendering HTML, and 0 otherwise, such as with CLI applications.

3 thoughts on “My Xdebug configuration

  1. One thing I noticed about the remote_connect_back setting though, is that it doesn't really work when debugging a CLI script from within a virtual machine. In those cases the remote_host setting should be used, set to the IP of the host machine on which the VM runs.

    1. I invoke CLI debugging with this env vars:

      export PHP_IDE_CONFIG="serverName=Dev-Docker"
      export XDEBUG_CONFIG="remote_host=172.17.42.1 idekey=phpsaltbox"
      

      HTH

  2. Thank you for the interesting blog post!

    Personally, I want execution to halt on any error but for some reason xdebug.halt_level does support neither E_STRICT nor E_DEPRECATED. Therefore I'm still using a custom error handler instead of Xdebug.

    Furthermore, a custom error handler seems to be the only way to enforce a "500 Internal Server Error" HTTP response code if an error occurs and "display_errors" is enabled (https://bugs.php.net/bug.php?id=50921).

Leave a Reply to Steffen Cancel reply

Your email address will not be published.