Logging Service
Last updated
Was this helpful?
Last updated
Was this helpful?
The is the only example of a service provided in the foundations module. That's because we believe that every plugin should use logging (hence also why every service is forced to implement the interface).
In short, the logging service is a multi-handler service that accepts any handler implementing the interface. It's expected to provide the service with two handlers, one with the ID framework and one with the ID plugin.
By default, the logging service attempts to log using the plugin handler, whereas messages logged by framework modules will always use the framework handler. In order to include sensitive data in the log messages, you need to instantiate the service with the second parameter set to true
.
The logging service doesn't understand what data is of sensitive nature and which is not. It's your responsibility to mark it accordingly when composing the logged message.
The requires an ID and a logger. We recommend using for your PSR-3 logger needs, but if you're building a WooCommerce plugin, please be aware that the provides a handler compatible with the WooCommerce logger.
Here is a simple example for instantiating the logging service using Monolog loggers:
The logging service provides two public methods:
log_event_and_finalize
-- shortcut for calling the log_event
method and finalizing the message.
Instances of the LogMessageBuilder
class need to have the finalize method called on them for the message to be logged and the other actions performed as well.
If you don't call finalize
on LogMessageBuilder
objects, the message will never be logged!
A few things that the message builder can do:
If the service is configured to ignore sensitive content, it removes all the text wrapped in <sensitive></sensitive>
tags.
By default, it returns null
when calling finalize
, but it can be configured to return the logged message wrapped in an exception or a given throwable object.
And here are examples on how to use the message builder (we'll assume the logging service instantiated above is present in this context as well):
log_event
-- returns an instance of the class which can be further configured to perform other actions before logging the message.
It can log the message using WordPress' as well.