harmonize severity/type in watchdog and drupal_set_message

Created on 17 August 2011, over 13 years ago
Updated 23 April 2025, 2 days ago

Problem/Motivation

drupal_set_message() accepts a $type parameter (string) that may be one of:

  • error
  • warning
  • status

The logging system, on the other hand, defines a different set of severities. Per Drupal\Core\Logger\RfcLoggerTrait, these include:

  • emergency
  • alert
  • critical
  • error
  • warning
  • notice
  • info
  • debug

To facilitate such features as automatic logging of messages (see, for example, ✨ drupal_set_message('whatever', 'error') should be integrated with logging Postponed: needs info ), these should be harmonized.

Proposed resolution

Both drupal_set_message() and the logging system should use the same values for their 'severity' or 'type' parameters for consistency. Likely this means that:

  1. drupal_set_message() should accept, as $type, an RfcLogLevel::* constant (though this seems to be a somewhat inappropriate use of RfcLogLevel since user messages have nothing to do, logically, with logging); or,
  2. drupal_set_message() should be entirely refactored into a some sort of 'UserMessage' service. This is already in consideration but postponed to 8.1.x at #2278383: Create an injectible service for drupal_set_message() β†’

Of course, drupal_set_message() is also on the path to obliteration altogether, per #2073817: [META] Remove drupal_set_message() β†’ and so this debate may be moot once postponed to 8.1.x.

Remaining tasks

As noted above, it is not yet clear precisely how this should be implemented, if it should be implemented at all. Further discussion about the merits of this change is required.

Postponing to 8.1.x because this is not needed to resolve a bug or issue prior to 8.x release. Implementation #1 above could likely be made without breaking backwards compatibility (by testing $type to determine if it is a string or an RfcLoggerTrait constant), but this is nonetheless an API change that is hardly critical to 8.x. Implementation #2 is clearly beyond the scope of a change at this stage. If this route is deemed advisable

User interface changes

Not yet determined.

API changes

Not yet entirely determined, but clearly this would require a change to the drupal_set_message() function to harmonize the 'levels'.

Beta phase evaluation

<!--Uncomment the relevant rows for the issue. -->
πŸ“Œ Task
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component

base system

Created by

πŸ‡¬πŸ‡§United Kingdom joachim

Live updates comments and jobs are added and updated live.
  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

Production build 0.71.5 2024