Issue #5014: Soften token status report messages, split into individual items with different severity values.

[klonos]

Fixes backdrop/backdrop-issues#5014

See: https://git.drupalcode.org/project/token/-/commit/b189c11160e8ef4a517f3e749ac8ebb791c29a99

NOTE!!!: This includes some of the changes in #4488 (which is an earlier commit than this one here) - pay attention to not revert changes, depending on which PR gets merged first.

Example of a status warning before:

After this change it becomes an "info" message:

[backdrop-ci]

Related to: backdrop/backdrop-issues#5014

[dragonbot]

Tugboat has finished building a preview for this pull request!

Website: https://pr4489-a88fm1kejef2fvlp67qozssxrssuxum4.tugboatqa.com/
Username: admin
Password: cb29b87da36f

This preview will automatically expire on the 4th of October, 2023.

[kiamlaluno]

I comment here because the related issue is for multiple PRs. I wonder if it makes sense to show, on /admin/reports/status, code errors as errors.

For an error caused by a missing dependency, I could install the module or the PHP extension that is required; in the case the error is about a PHP extension I could not install (for example because my hosting provider does not include it between the available extensions), I can at least uninstall the module showing the error on the reports page.
If the error is about the $settings['trusted_host_patterns'] value that is not defined, I can open the settings.php file and change the lines that define $settings['trusted_host_patterns'].

For a Tokens or token types not defined as arrays error, which does not identify the module causing it, I would not know what to do. I should disable all the modules that define tokens, one by one, and check all the times if the error vanished, which is not that easy if the module that causes the error is required by another module (and I am not allowed to disable it before disabling all the dependent modules).

[klonos]

I wonder if it makes sense to show, on /admin/reports/status, code errors as errors.

Sorry @kiamlaluno, can you please clarify? Are you saying that all these problems should be flagged as errors? Before this change, everything was flagged as a warning. With this change, some will be shown as errors, some as warnings, and some as info. Is that what you are suggesting to be changed?

Since the respective 7.x commit was not linked to any issue in d.org, I couldn't find any discussion around this change 🤷🏼 ...do others think that we should omit it?

[kiamlaluno]

I meant that I would not show, on the reports, errors that say that some hook did not return the right value, especially when the error does not make clear which module caused it. If showing those errors on the reports page is mandatory, I would rather show them as warnings.

[kiamlaluno]

The issue that introduced that code in the Token module is Improve checking for token definition problems, where the last comment is the following one.

Committed #᠎5 to Git. Still needs improved reporting on 'which' modules are the violators.
http://drupalcode.org/project/token.git/commit/6cfd59b

That issue's status is still Need work.

Drupal 8, although it has tokens in core, does not contain code similar to that one.