Why rely on Drupal routes to serve generated images for every request?

Automatically closed - issue fixed for 2 weeks with no activity.

Since this issue already exists I will add the changes here, initial PR for an alternative method of loading images similar to what core uses for image styles.
This solution changes the URLs to the physical path of the generated file and falls back to the router using a kernel event listener.

Hoping for the maintainer(s) to reopen this issue.

We have created a fork of the module ( https://www.drupal.org/project/drimage_improved → ) to demonstrate a fully functional module that uses an alternative image loading method similar to what core uses for image styles.

This forked module is largely similar to the current pull request (PR), with the main difference being the introduction of some install hooks to replace Drimage plugins as drop-in replacements.

Our intention is not to maintain or keep this fork if the PR is merged. We hope that this PR is merged with the improvement logic, which offers a significant performance boost compared to redirects and Drupal bootstrapped-image serving.

Once the PR is merged, we can shut down the fork and fully rely on the Drimage module.

I'll reopen and try to make some time to review this. Sounds like a much better approach!

Great! Happy to discuss if you have any questions.

I did some small tests and have some feedback.
I will try and make some more time this week to further test and maybe try and get this fully working but feel free to help me out here ;)

1/
The first request causes a redirect. Is this something we can avoid?

2/
The image_widget_crop handling contains an error. See revised code below that does work correctly.

      if ($this->moduleHandler->moduleExists('image_widget_crop') && isset($style_parts[3])) {
        $width = $style_parts[1];
        $height = $style_parts[2];
        // Need to implode all parts from index 3 and further to get the correct iwc_id.
        // The image widget crop id itself can contain underscores.
        $iwc_id = implode('_', array_slice($style_parts, 3));
      }

3/
Do we need the same kind if checks for the focal_point integration?

4/
I think there is some code + documentation and example to rewrite url's via apache vhosts: this will need to change also.

5/
Is there any other code we can delete once this new delivery mechanism is in place?

Fixed in the forked Drimage Improved project
🐛 Redirect to 404 Page for Invalid Image Paths Fixed
Better to have a look at the latest changes at
https://git.drupalcode.org/project/drimage_improved

Thanks a lot for the idea of Drimage, BBC, CNN, and more are using this idea

At this point we only can create MR from an issue fork, no direct project fork in Drupal.org

Any possibility of updating the MR instead of forking?

I am willing to commit to get this working within drimage itself.
But comparing the forked module to the drimage, porting over changes and testing them, is not making this easy for me... :(

Hello @weseze
Regarding the redirect issue, I'm doing some work here https://git.drupalcode.org/issue/drimage_improved-3456741/-/compare/1.0.... but since there was a lot of functionality in the controller I ended up moving it to a new service.
Please have a look and let me know what you think if you can.

Thanks for the work! I'll make time at the end of the week and try and get it merged in and released.

Thanks for all the work.

I updated DrimageSubscriber to use rawurldecode() because image style url is generated via FileUrlGenerator that uses Drupal\Component\Utility\UrlHelper::encodePath() which uses rawurlencode() to encode path.

The difference is small, but if user decides to use + symbol in file name, it would be decoded as space instead of plus and this results in "Image not found".