[10] Fix automated test results - Support for keys without a placeholder prefix is deprecated (Rules)

The strings above all come from our debug logging code.

I looked at this a bit and my impression is that this is a false positive caused by the difference between PSR-3 logging used by Symfony and Drupal logging. The former uses different placeholders and has different parameters, and Drupal core performs some gymnastics to bend its logging into the shape required for Symfony.

For example, the Symfony log($level, $message, array $context = []) requires that $message is a string with PSR-3 placeholders, and $context is an array of placeholder replacements and other things. While Drupal logging (e.g. the messenger service) requires a message string to be either a plain string or a FormattableMarkup object created by t($message, array $placehoders), but specifically there is no separate argument for placeholders.

It's those "other things" in $context that are causing a problem - they are not being passed as placeholders, but as additional data needed by the logger at a different point in the code. Thus they don't have prefixes like placeholders do, and they shouldn't need prefixes. It seems to me that the deprecation notice is being a little too aggressive when checking prefixes, because it's assuming everything in $context is a placeholder when that's not true.

Drupal does have a compatibility layer, which we use already. See for example this code in RulesLog:

     // Convert PSR3-style messages to \Drupal\Component\Render\FormattableMarkup
    // style, so they can be translated at runtime.
    $message_placeholders = $this->parser->parseMessagePlaceholders($message, $context);

There may be a workaround to avoid this deprecation notice by artificially renaming some of the keys in the $context array so that they look like placeholder keys, but that's not something I'm interested in investigating right now.

From https://api.drupal.org/api/drupal/vendor%21psr%21log%21Psr%21Log%21Logge...

The context array can contain arbitrary data. The only assumption that can be made by implementors is that if an Exception instance is given to produce a stack trace, it MUST be in a key named "exception".

So in this case, the Symfony specification clearly states that $context is not used just for Drupal placeholders, meaning the keys do not have to conform to Drupal placeholder key names with prefix.

And specifically in some cases you MUST use a key named "exception", which would also trigger the above deprecation notice.

This strengthens my initial impression that this deprecation is a false positive in our case, caused by Drupal core being too aggressive at identifying what is a placeholder. So if I were going to work on this (which I'm not, at the moment), the way I would approach it is to investigate that core Drupal deprecation notice with the intention of rolling a patch for core to remove the assumption about the contents of the $context array.

Postponed, waiting for resolution of #3173103: False positives when identifying what is a placeholder, for deprecation error

Opening up again because in Drupal 10 this issue is the cause of our only test failures.

Trying something ...

Well that's embarrassing. Here's a corrected patch.

The tests got further, but identified another place that needs to be modified. If I get this working I'll refactor the code to make it nicer - this patch is just trying a theory.

The code in this patch is optimized and documented.

Committed.