Skip to main content

In Drupal, the logging system is based on the PSR-3 logging standard, which Drupal integrates through the \Psr\Log\LoggerInterface. When you want to log messages, you typically use placeholders in your message string, which are replaced with context array values. However, if you're dealing with a situation where you have a complex message or an object implementing the \Drupal\Core\Logger\RfcLogLevel\MessageInterface, and you want to log the entire object or message as it is, you might need to handle it differently since the logger interface expects a string message and an array of context data.

The \Drupal\Core\Logger\RfcLogLevel\MessageInterface is not directly related to logging messages but rather to defining RFC log levels. For logging complex messages or objects, you should convert the message or object to a string format, if possible, or serialize it to a string representation that can be logged.

Your approach to logging an entire object or a complex message, by serialising or converting the object to a string

// Get the logger service.
$logger = \Drupal::logger('your_module_name');

// Check if the $message can be directly converted to a string or needs serialization.
if (is_object($message) && method_exists($message, '__toString')) {
   // If your object can be converted to a string, use __toString().
   $log_message = $message->__toString();
} else {
   // Otherwise, serialise the object to a string.
   // Note: Serialisation might not be suitable for all objects, especially if they contain resources or sensitive information.
   $log_message = serialize($message);
}

// Log the message.
// You might want to use a specific log level like debug, info, notice, warning, etc.
$logger->notice($log_message);

Please ensure that serialisation is suitable for your use case, as it might not be the best approach for all types of objects, especially for those containing resources or sensitive data. Also, note that using serialisation can make the log harder to read, so for debugging purposes, you might consider logging specific properties of the object instead.

Remember to replace 'your_module_name' with the actual name of your module. This code snippet assumes that you're working within a context where \Drupal is available; if you're working in an object-oriented context (like a service or a controller), it's better to inject the logger service rather than calling \Drupal::logger().

Related articles

Andrew Fletcher04 Apr 2025
Managing .gitignore changes
When working with Git, the .gitignore file plays a critical role in controlling which files and folders are tracked by version control. Yet, many developers are unsure when changes to .gitignore take effect and how to manage files that are already being tracked. This uncertainty can lead to...
Andrew Fletcher26 Mar 2025
How to fix the ‘Undefined function t’ error in Drupal 10 or 11 code
Upgrading to Drupal 10.4+ you might have noticed a warning in their code editor stating “Undefined function ‘t’”. While Drupal’s `t()` function remains valid in procedural code, some language analysis tools — such as Intelephense — do not automatically recognise Drupal’s global functions. This...
Andrew Fletcher17 Mar 2025
Upgrading to PHP 8.4 challenges with Drupal contrib modules
The upgrade from PHP 8.3.14 to PHP 8.4.4 presents challenges for Drupal 10.4 websites, particularly when dealing with contributed modules. While Drupal core operates seamlessly, various contrib modules have not yet been updated to accommodate changes introduced in PHP 8.4.x. This has resulted in...