Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
In most cases, drupal_set_message() is just another channel for reporting information along with logging, and should be handled as such instead of requiring duplicate calls with inconsistent parameters.
Before anything else is done, we need to reach some consensus on whether this is desirable in the first instance. The motivation is to reduce the need for callers to send the same message to two channels (a logger and drupal_set_message()), but in many (most?) cases, the intended audience is different and it may not make sense to send the same message to both places.
Example 1: A form validation "error" because a user neglected to enter their zip code when creating a new account in is not necessarily an error that should be logged. Autorouting the drupal_set_message() call to the logger would be frivolous.
Example 2: In the event of a critical site error or database problem, it might make sense to send to the logger complete details (including the failing SQL statement and other details) while you would clearly not want this displayed to the end user (outside of a development environment).
On the other hand, a case might be made that UX developers and designers might in fact be interested in knowing which forms routinely result in validation errors (to spot fields or schemas that end users are regularly becoming confused about).
Proposed resolution
First, for this to happen in any automatic sense, the "error levels" or "categories" passed in the $type parameter to drupal_set_message() should be harmonized with the former watchdog() "error levels" (now provided for in Drupal\Core\Logger\RfcLoggerTrait). This element is essentially a duplicate of #1251960: harmonize severity/type in watchdog and drupal_set_message and should be addressed in that issue.
Second, it has been proposed that messages set via drupal_set_message() should also be sent to the system logger.
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 a feature request, along with its related issue, will cause backward compatibility issues and potentially drastically changed behaviour.
User interface changes
Not yet determined.
API changes
Not yet entirely determined, but clearly #1251960: harmonize severity/type in watchdog and drupal_set_message would require a change to the drupal_set_message() function to harmonize the 'levels'.
Beta phase evaluation
| Issue category | Feature, because this introduces new functionality (linking drupal_set_message() with logging). |
|---|---|
| Issue priority | Normal and not-critical because it affects multiple systems but is not necessary for stabilization of core. |
| Prioritized changes | This is not a prioritized change for the beta phase. |
| Disruption | Potentially disruptive for core, contributed and custom modules because there would need to be some way of indicating which messages should be passed to both channels and which should not, and the related issue of harmonizing logging/status levels will require a BC break and widespread changes. |
Comments
Comment #1
Crell CreditAttribution: Crell commentedI'm not convinced of this. The error message I show to the user should be user-friendly, and help a user know what to do next. A legged error message should be developer/admin-friendly, and tell the developer/admin what to do to keep it from happening again. Variable dumps, for instance, make sense in the log message but not in the flash message. That many modules use the same string for both is not a feature; it's a lazy bug. :-)
Comment #2
marcingy CreditAttribution: marcingy commentedThis can't be considered a bug this is a task at most.
Comment #3
BerdirAs a simple counter-example, there's absolutely no need to log things like validation errors as watchdog errors.
Not convinced either, don't think this makes sense.
Comment #4
fgmAs errors, obviously not. But a UX team might wish to get a log of validation errors channelled to them to work on usability of their screens, for example: it seems limiting to have core decide that such information will not be available by default, forcing teams to add extra code to handle such data acquisition needs.
Crell makes a good point, though: these functions target different audiences, and although most events may (or not) be of interest to both, the content of the data needed in both cases may often be subtly different : no exception stack traces for end users, and no sugary meaningless messages for devs.
Comment #5
XanoThen we should add a debugging mode to watchdog that, when enabled, maps severities, runs messages through t() and displays them. This can probably even be done using a simple contributed module that implements hook_watchdog().
Comment #6
tibbsa CreditAttribution: tibbsa commentedComment #7
tibbsa CreditAttribution: tibbsa commentedIssue summary revamped and marked as postponed to 8.1.x as this amounts to a feature request and, in tandem with its related issue, will require API changes. None of this is important or critical to core at this stage.