🇫🇷France @nanak

Well, the why do not really matter: it's a supported behavior according to symfony documentation, which works without the patch, so I'd say it is a problem, since it's a regression.

https://symfony.com/doc/current/configuration.html#configuration-parameters

If some parameter value includes the % character, you need to escape it by adding another %, so Symfony doesn't consider it a reference to a parameter name

I suspect some kind of double resolution of parameters within a compiler pass (or rather, two passes); but I can't say which one, nor why it kicks twice

It's not related to monolog, it's just the mean through which I found the issue, it can be reproduced using core only (this project uses 10.3.14):

In a parameter_test_module.services.yml:

parameters:
  broken_parameter: '%%somevalue%%'
  
services:  
  parameter_test_module.example:
    class: Drupal\parameter_test_module\Example
    arguments: ['%broken_parameter%']

Upon clearing caches:

drush cr
In ParameterBag.php line 93:                                   
  You have requested a non-existent parameter "somevalue".

Without the patch, the parameter is properly registered in the container as broken_parameter: '%%somevalue%%'

I'm getting a weird issue with an edge case. Reading the comments above, its seems to be related with the issue encountered in #20 📌 Support setting service parameters via environment variables Needs work #21 📌 Support setting service parameters via environment variables Needs work & #22 📌 Support setting service parameters via environment variables Needs work

I have monolog installed, and in the parameters section of monolog.services.yml, have these entries (shortened):

parameters:
  syslog_format: '%%channel%%|%%datetime%%|[...]|%%message%%'
services:
    monolog.formatter.syslog_line:
      class: Monolog\Formatter\LineFormatter
      arguments: [ '%syslog_format%', 'U' ]
      shared: false

With the patch installed, rebuilding caches fails with the following error:
You have requested a non-existent parameter "channel". Did you mean this: "monolog.channel_handlers"?

Basically, %%channel%% is interpreted as %channel%, so it tries to resolve the string as a service parameter named channel.
If I then try to escape this sequence (so %%%%channel%%%%), the registration succeeds, but the parameter is registered as %%channel%%, while it should be stored as %channel%

A weird workaround I found to work is the following:

parameters:
  env(MONOLOG_SYSLOG_FORMAT): '%%%%channel%%%%|%%%%datetime%%%%|[...]|%%%%message%%%%'
services:
    monolog.formatter.syslog_line:
      class: Monolog\Formatter\LineFormatter
      arguments: [ '%env(string:MONOLOG_SYSLOG_FORMAT)%', 'U' ]
      shared: false

That way, registration succeeds, and the parameter is stored as expect, with a single %.

Attached merge request which:
- Updates .gitignore to ignore composer manged files
- Adds .gitlab-ci.yml.dist file, supporting artifact base deploy. Must be renamed .gitlab-ci.yml to leverage it
- Move dropsolid/ddev-drupal to require-dev section, and bump to ^0.7.0
- Disallow new "tbachert/spi" plugin (see https://www.drupal.org/node/3492353 → )

nanak → created an issue.

Rerolled for 10.1.x / 11.x

Note that the above patch applies on top of #10

I've been using class names as service id before 9.5 and it used to work, but I've made a mistake: this won't work with Drupal 9 at all due to the '@.inner' notation, which got introduced in Symfony 5.1, so only available from Drupal 10.0 onward.

Attached, a patch using the syntax supported by both Drupal 9 and Drupal 10. I tried it on a Drupal 9.3 fresh install, and the service could properly be registered this time. Sorry for the mistake.

According to https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → , Drupal 9.5 is no longer marked as compatible with PHP 7, and supports PHP 8.0 & 8.1.

Nevertheless, the attached patch should be compatible with PHP 7.4, and I removed the strict types check.

Hi, attached a patch inspired by the above MR, using a service decorator, available only if stage file proxy is installed, and works on the first request.

Supports stage file proxy >= 2.0.3, as the decorated service was introduced in the version.

About your remark in the previous comment "I'm guessing that this piece of code will need some extra checking for stage_file_proxy to fetch the original image before proceeding.": this is the case, the event subscriber fires and fetches the image before the drimage controller comes into play

Thank you @chetan, that was already done in the merge request.

nanak → created an issue.