As of Drupal >=7.22, this is possible! Patch is attached, though currently it has to be enabled manually:
drush vset drupal_http_request_function tracelytics_drupal_http_request
This works quite similarly to an existing cURL layer, generates a backtrace, and supports full-stack application tracing (propagates the X-Trace header). I've marked it as major, as it should provide a lot of insight into currently missing calls (like the Solr module).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 0001-drupal-Provide-an-override-function-to-trace-drupal_.patch | 5.12 KB | Eronarn |
| 0001-drupal-Provide-an-override-function-to-trace-drupal_.patch | 2.48 KB | Eronarn |
Comments
Comment #1
Eronarn commentedComment #2
pdrake commentedThis looks pretty good - some minor notes below. Also, I would like to see an option for this in the admin settings form. You can check the VERSION constant using version_compare to enable/disable the option.
This should use single quotes around the colon and could use the logic from drupal_http_request: isset($uri['port']) && $uri['port'] != 80 ? ':' . $uri['port'] : '';
Personal preference here, I wouldn't mind seeing the global declaration at the beginning of the function.
This will remove the newline at the end of the file.
Comment #3
Eronarn commentedI agree about the admin setting being necessary, but I wasn't sure how to use system_settings_form to best handle the requirement for the variable to be either not present or set as tracelytics_drupal_http_request... just a checkbox won't work unless we also add a handler.
Comment #4
pdrake commentedI think a checkbox should be fine. It would be unchecked if that variable is empty, checked if it is set to tracelytics_drupal... and disabled if it is set to anything else (with a description as to why it is disabled), right?
Comment #5
Eronarn commentedHere's a reroll of that patch with the above changes, I think it still needs work but it should be closer at least
Comment #6
pdrake commentedThis is committed to 7.x-1.x.