If you call trigger_error('Some message') in your code (thereby trigger a message with the default E_USER_NOTICE error type), it will get displayed to the screen as if it is a debug message generated with the debug() function (in other words, it will have the word "Debug" out front, will display as a green status message rather than a red error message, etc).

That behavior was introduced in #296574: Provide debug facility for general and testing (with some reservations) as a means of getting debug() to behave properly.

Currently it is causing me some issues with the patch in #2844716: "Missing/moved modules" PHP warnings should be PHP notices instead.

I think the solution is to use a method similar to https://api.drupal.org/api/drupal/includes!bootstrap.inc/function/_drupa... to indicate that only the messages triggered by the debug() function should be displayed as debug messages.

CommentFileSizeAuthor
#4 2844732-4.patch5.28 KBDavid_Rothstein
#3 2844732-3.patch1.26 KBDavid_Rothstein
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

David_Rothstein created an issue. See original summary.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented
Issue summary: View changes
David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented
Status: Active » Needs review
FileSize
2844732-3.patch1.26 KB

Here is a patch.

I guess ideally it would have tests, but I don't really have the inclination to write them at the moment.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented
FileSize
2844732-4.patch5.28 KB

Hm, it actually may be a bit more complicated than the above. There is duplicate code elsewhere that does the same thing, and also code in the tests that seem to rely on it.

Here's a new version of the patch that I think may be complete this time.

Status: Needs review » Needs work

The last submitted patch, 4: 2844732-4.patch, failed testing.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone CreditAttribution: quietone at PreviousNext commented
Issue tags: +Bug Smash Initiative

This is a Bug Smash daily triage issue.

errors.inc has the following but there is no explanation why a 'User notice' is to be treated as debug information.

      // If error type is 'User notice' then treat it as debug information
      // instead of an error message.
      if ($error['%type'] == 'User notice') {
        $error['%type'] = 'Debug';
        $class = 'status';
      }

Git blame says that this was introduced in #325169: Move error/exception handler higher up in the bootstrap process but that is not right. The change is not there. The IS has #2844716: "Missing/moved modules" PHP warnings should be PHP notices instead and looking there, the patch has:

       // If error type is 'User notice' then treat it as debug information
		-      // instead of an error message, see dd().
		-      if ($error['%type'] == 'User notice') {
		+      // instead of an error message, unless we know it came from somewhere
		+      // other than debug().
		+      if ($error['%type'] == 'User notice' && !drupal_static('_drupal_trigger_error_with_delayed_logging')) {
		         $error['%type'] = 'Debug';
		         $class = 'status';
		       }

I don't know what _drupal_trigger_error_with_delayed_logging' is and so still don't know why 'User notice' are treated as debug in the UI.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.