- Issue created by @ysamoylenko
- last update
about 1 year ago 29,469 pass - Status changed to Needs review
about 1 year ago 2:42pm 28 August 2023 - Status changed to Needs work
about 1 year ago 3:42pm 28 August 2023 - πΊπΈUnited States smustgrave
Thank you for reporting.
As a bug could we get a test case showing the issue please.
- First commit to issue fork.
- πΊπ¦Ukraine mr_fenix
Hello,
I have reviewed this issue to be helpful, and it appears to me that this patch does not resolve the issue for the following reasons:
1. There is no need to add this parameter because it's already accounted for in the \Drupal\Core\Utility\Error::logException and \Drupal\Core\Utility\Error::decodeException methods.
2. Honestly, this issue doesn't seem to be a problem with the core as Drupal loggers don't use this in formatting https://git.drupalcode.org/project/drupal/-/blame/10.1.1/core/lib/Drupal...
without this
https://git.drupalcode.org/project/drupal/-/blob/10.1.2/core/lib/Drupal/...
for indices severity_level and exception (see the decodeException method).
So, I think you're using a logger specific to your system that uses FormattableMarkup (possibly indirectly), which doesn't parse $context with LogMessageParser::parseMessagePlaceholders first.3. In any case, starting from the core version 10.1.5, the formatter has been changed https://git.drupalcode.org/project/drupal/-/blame/10.1.5/core/lib/Drupal... ,
and now there's no chance to get such warnings when these variable keys don't match.Therefore, I suggest just close this issue, because the parameter already supposed to be added in code and in core 10.1.5, it works as expected (without warnings, please see FormattableMarkup), even if FormattableMarkup are used incorrectly. For lower version it seems it should be used correctly.
Thanks
- Status changed to Closed: works as designed
9 months ago 11:28am 3 March 2024