Needs review
Project:
Drupal core
Version:
main
Component:
dblog.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 May 2026 at 15:55 UTC
Updated:
14 May 2026 at 16:17 UTC
Jump to comment: Most recent
Problem/Motivation
When something enters a NULL value for a placeholder when logging a log message, the Recent Log Messages view will break completely, with a TypeError bubbling up all the way to the top. Of course, a NULL value for a placeholder is probably an error in its own right, but I'd like to argue this should not break the Recent Log Messages overview.
An example of the error:
Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in /var/core/www/core/lib/Drupal/Component/Render/FormattableMarkup.php
Steps to reproduce
Create a small testing module
Write a log message using e.g. $logger->error('Message with a @placeholder', ['@placeholder' => NULL]);
Visit the recent log messages overview at /admin/reports/dblog
Watch it throw a TypeError
Proposed resolution
Replace NULL values with the string "NULL" before formatting the message.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3589365
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
eelkeblokComment #4
eelkeblokComment #5
eelkeblokIncidentally, I ran into this while testing https://drupal.org/project/s3fs against Cloudflare R2. The module produces a log message for a failed request (I had my authentication wrong) that contains a placeholder for a request ID. For some reason the response did not contain a request ID, and the method that should produces it returns NULL. This probably also needs a fix there, but the entire recent logs blowing up felt significant too 🙂
Comment #6
dagmarSeems related to #3589729: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in /var/core/www/core/lib/Drupal/Component/Render/FormattableMarkup.php and #3143942: Warning: htmlspecialchars() expects parameter 1 to be string, array given in Drupal\Component\Utility\Html::escape()
Comment #7
dagmarI guess the error mentioned in https://git.drupalcode.org/project/drupal/-/commit/a335588be26ad7054b3fb... is what is happening now. The problem boils down to decide if we agree a miss use of the api when creating logs, or try to recover from an invalid logged error.
Comment #8
mingsongComment #9
eelkeblokI guess the issue linked by mingsong is indeed a duplicate and more mature. Closing.
Comment #11
eelkeblokActually, I was probably too fast. That is a long and complicated issue I have not fully understood what the intention is yet. It seems it might actually resolve this too, but in a more fundamental way. I'll leave this as needs work for now, I guess it needs some more srutiny to see whether this issue would be resolved when #3554974: FormattableMarkup: NULL @ and % placeholder values should log a notice and use empty string is resolved.
WRT #7, I think that even a misused API should not cause the log screen to break. Ideally, the API should probably be made more resilient, preventing the misuse (which I think the other issue is about), but that is somewhat out of scope for this issue. This is simply about the log overview screen not blowing up when some code has entered bad data into a log message.
Comment #12
eelkeblokIt looks like that at least the current state of the other issue does not prevent this issue once a NULL has entered the database, so I guess this still has merit.