Do not regenerate the webp file each time it is requested

Reroll attached.

Moving this to major.
This brought our high-traffic site down multiple times before detecting the issue.

Very important patch, thank you
Works as expected

+1 Patch #5 is working for me

re #5 - we may want to provide a shorter lock acquisition period. According to the docs, it defaults to 30 seconds.

float $timeout: (optional) Lock lifetime in seconds. Defaults to 30.0.

In the event that disk access is slow (mounted filesystem, perhaps?), this could introduce a denial of service vector.

Since the Retry-After timing is set to 3 seconds, would it also make sense to reduce the lock acquisition time to 3 seconds as well?

we can fix it with simply check with file_exists. Not sure.. why do we need with lock solutions here?

This patch would fix it.

re #9: I think the purpose of the lock is to prevent broken images on the frontend while an image is generating. Retry-After wasn't widely supported last I knew. Locking for N seconds is a pretty good workaround in the short term. Otherwise, sites could still have image derivatives generated more than once if a lot of requests hit the page at the same time.

I'd imagine that this could be an issue for high volume traffic sites in particular.

This is the patch for the current MR. Uploading to have a stable patch for my build.

could you have a look at this @jedihe so we can merge ?

Merge blocked: fast-forward merge is not possible. To merge this request, first rebase locally.

https://git.drupalcode.org/project/webp/-/merge_requests/3

1. +++ b/src/Webp.php
   @@ -81,7 +94,38 @@ class Webp {
   +    $success = file_exists($destination) || $this->createWebCopy($uri, $destination, $quality);
   

   Better not to rename this method, as it's called as well from FileDownloadController

2. +++ b/src/Webp.php
   @@ -81,7 +94,38 @@ class Webp {
   +  protected function createWebCopy($uri, $destination, $quality = NULL) {
   

   Needs a docblock.

Rebased and updated branch with requested edits.
Here is a rerolled patch as well.

The MR and the patch don't apply anymore. At least composer complains about it.

Attached is an updated patch for the current 1.x-dev version, based on the MR.

Attached is patch from #21 + #3256454-2: Error "Could not generate image resource from URI" on non-image formats because we need both on our project.

The maintainers most likely will want to review #21.

Rerolling #21 to work with RC1 release.

Rerolling #22 to work with RC1 release.

This issue is related to #3435835: Webp derivatives not refreshed when files stored in sub-directory. When that other issue is merged, the code in the new getWebpCopy() method provided by this patch will need to be updated to
$destination = $this->getWebpDestination($uri, '@directory/@filename.webp');

Can someone provide steps to reproduce? Does this only occur when using Webp with private files?

I tried adding debugging code to the generation method, and it fires when the image is first uploaded, but not when the image is requested again.

I'm not able to reproduce the problem in #3435835: Webp derivatives not refreshed when files stored in sub-directory any more. Maybe there was a particular combination of versions and patches I was using that caused it. I've struck through my comment above so it doesn't cause confusion