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.
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.
I invoke CLI debugging with this env vars:
HTH
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).