Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Given that HTTP requests receive an array of options, which could include useful metadata, it could be handy for modules to make use of some of those options in hooks that are fired when saving a log entity.
For example, I could add a field for storing a 'type' of request, and when a certain custom option is passed (which Guzzle itself would ignore), my custom module could make use of hook_entity_presave() or hook_http_client_log_presave() to populate that field from the custom option. I could then use that field to filter or group logs by.
I'm not asking for this module to actually do any of that, but merely to pass along the full $context variable so that other modules can then make use of it. They could do other interesting things with the original Request & Response objects that are in there too, if they wanted. I'll provide a patch!
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | http_client_log-pass-context-3356864-2.patch | 1.13 KB | james.williams |
Comments
Comment #2
james.williamsHere you go - a nice & simple patch :) The context array will be available in hooks via
$entity->context, and will get otherwise ignored whilst saving a log entity.Comment #3
zterry95 commentedIn this case, service decorator is a better option; http_client_log.services.yml is an example.
Comment #4
james.williamsI'm well aware that service decorators could be ideal (and I have implemented many before elsewhere); but I don't see how that would help here? I'm looking for a way to get something from the options array, into the log entity. The log entity is created inside
\Drupal\http_client_log\Logger\Logger::log(), and as far I can see, that whole method would need replacing in order to do this, so decoration couldn't really help, unless that class was first rearchitected to introduce an opportunity in between the entity being created and saved?If decoration, or replacing the service class was used, there's not much from this module that's actually left in use, beyond the entity type definition. Which seems a shame! My suggestion to include the context in the log entity is simply to make the data available so that there is an opportunity for extensibility.
Or can you help me see how decoration could actually be used to take input from the options array, to set field values on the log entity, given the current module code?
Comment #6
zterry95 commentedHi James, commited.
Comment #7
james.williamsThanks very much!