View Issue Details

IDProjectCategoryView StatusLast Update
0002077XdebugTracingpublic2023-11-30 14:50
Reportermatt Assigned Toderick  
Status closedResolutionfixed 
Product Version3.1.2 
Target Version3.3devFixed in Version3.3.0 
Summary0002077: Bring back xdebug.collect_params

I use trace dumps mostly to:

  • generate stack traces, collapse them, generate performance flame graphs,
  • debugging,
  • research & discovery tool of how new code works.

While having xdebug.collect_params always on is sometimes useful, most of the time parameters are not necessary for my use. Parameters make the trace files much bigger and when greping them they clutter output. Parsing of the trace files might also require more memory and might be slower. Could you consider bringing back xdebug.collect_params setting?

I'm open to paying for implementation of this feature.

Operating System
PHP Version7.4.20-7.4.29



2022-03-28 17:12

administrator   ~0006258


I'm a little reluctant adding INI settings again, as I tried so hard getting rid of them. Would adding a new flag to xdebug_start_trace perhaps be an acceptable alternative? I realise that that means you need to call a function at your entry point.



2023-01-24 14:10

reporter   ~0006505


I also would appreciate if you could bring back the xdebug.collect_params setting. I generate xdebug traces from website requests on a regular basis. Without collect_params settings, the traces, with all parameters included, reach sizes up to multiple gigabyte, even if compression is used. A flag to xdebug_start_trace would be no alternative because the trace is started through a cookie (xdebug.start_with_request = "trigger").

Cheers, Daniel


2023-01-24 14:26

reporter   ~0006506

Sorry @derick, I missed your reply somehow.

I can't add xdebug_start_trace() because I'm not in total control of the environments I work with. I'm often in the role of "debug guy"/devops guy. I can set up my own php-fpm instance on a server with Xdebug enabled and direct carefully selected traffic to it via a web server ( e.g. based on my IP address), but I'm not able to modify the source code. Sometimes issues happen only on production, and all parties are extremely reluctant to modify application source code there (again, my php-fpm instances with XDebug enabled are always properly secured from 3rd party access).


  • this might skip auto-prepend files,
  • it's rather cumbersome when there's more than one main file that handles requests (for example WordPress)


2023-02-03 14:53

reporter   ~0006513

Hi @derick,

I understand your concerns about adding INI settings again, but I would like to bring up the convenience factor for users who would like to have the xdebug.collect_params feature like me.
Having an INI setting for this feature would allow users to quickly and easily enable or disable it without the need to modify xdebug which also is not common in production use.
I would like to suggest that you consider bringing back the xdebug.collect_params INI setting in addition to the xdebug_start_trace flag, as this would provide users with more options and flexibility.

Thank you for your time and consideration.

Best regards,


2023-09-18 15:17

administrator   ~0006657

Issue History

Date Modified Username Field Change
2022-03-18 08:27 matt New Issue
2022-03-18 08:27 matt Tag Attached: trace
2022-03-28 17:12 derick Assigned To => derick
2022-03-28 17:12 derick Status new => acknowledged
2022-03-28 17:12 derick Note Added: 0006258
2023-01-24 14:10 dan6209 Note Added: 0006505
2023-01-24 14:26 matt Note Added: 0006506
2023-02-03 14:53 marceldavis Note Added: 0006513
2023-07-21 16:30 derick Target Version => 3.3dev
2023-09-18 15:17 derick Status acknowledged => confirmed
2023-09-18 15:17 derick Note Added: 0006657
2023-09-18 16:04 derick Status confirmed => closed
2023-09-18 16:04 derick Resolution open => fixed
2023-09-18 16:04 derick Fixed in Version => 3.3dev
2023-10-19 15:40 derick Fixed in Version 3.3dev => 3.3.0alpha3
2023-11-30 14:50 derick Fixed in Version 3.3.0alpha3 => 3.3.0