Refactor ImageStyleDownloadController so derivatives can be generated by contrib modules

This is nice, but not help when more than one module needs to override the controller, e.g. stage_file_proxy and webp and avif. I'm wondering if it would be possible to have a service that can be decorated by multiple modules instead? See https://symfony.com/doc/current/service_container/service_decoration.html for details on service decoration in symfony. Then the ::deliver method can just call a method on the service and each module can decorate it with it's own behaviour.

Some update here and a "redo" of the patch for Drupal 11

[replace patch by a cleaner one]

Can you please put that code on a merge request? Tests don't run against patches anymore.

drdam → changed the visibility of the branch 2685905-refactor-imagestyledownloadcontroller-so to hidden.

Merge Request available

Thanks for converting to an MR.

Noticed that the summary appears incomplete, would recommend using the standard issue template.

Also will need test coverage for the new functionality

Thanks

For test coverage, I don't what it need to be tested, it just code management, no new functionnality.

Thanks for MR.
Do you think we can add interface for these new methods?

In the issue summary it states

- with S3...

What does that mean? With (in the case of) the S3 contributed module? Or with the S3 stream wrapper?

Then

..we want to first serve an image locally..

Who is 'we'? The reporter's company? Drupal.org?

How does 'we' 'want to first serve an image locally'? By using or creating a contributed module? Or a custom module?

I dont know the answers to these questions. If someone would like to update the issue summary or I will if I can get answers to these questions.

@nikolay shapovalov :
"Do you think we can add interface for these new methods?"

I don't know ...
The purpose of the RM is simply to separate the processing/generation of the derivatives from the various validation/authorisation operations linked to this generation.

@oily : I don't know either what @deviantintegral want to say, when it create the issue.
I just done my best when @smustgrave ask me to update summary to the "good template"
I have my use case "with mediaContextualCrop, we want to create a new image delivering methodebased on 80% of the ImageStyleDownloadController" for the others I don't know their motivations.

The test coverage could be following the steps to reproduce.

Will slightly agree with @nikolay shapovalov feels like an interface now.

I just add the interface, but I have a doubt about making all methods public ... if some one can check

I've faced issues related to the namespace and the missing return type of the isSchemePublic method.
The .patch file is attached for the people who don't want to add thousands of commits to their patch section inside composer.json.

@drdam:
"I just add the interface, but I have a doubt about making all methods public ... if some one can check"

I don't think that we need to put into the interface methods that aren't planned for external usage. So, I believe we should describe only the method "deliver" as the one that could be executed externally(I might miss something because I spent a little time checking the code.)

Still appears to be missing test coverage. May need a CR for the new interface too, I should of mentioned before that's on me.