Asset transforms are not regenerated when missing

[msimpson]

Description

If an automatically generated transformed image file or parent folder(s) are manually deleted they are never regenerated without manual intervention. Note, I understand the asset transform index can be cleared under clear caches but this feels like something which should be caught automatically.

Steps to reproduce

1. Create an image transform in a template.
2. View a page using said template.
3. Manually delete the automatically generated transformed image file.
4. Reload the same page and find that the image is now missing (resulting in a 404).

Additional info

• Craft version: Craft Pro 3.4.16
• PHP version: 7.4.3
• Database driver & version: MySQL 5.5.5

[andris-sevcenko]

@msimpson that's hard to catch without making it expensive. It's simple for locally stored transforms, but, if this is, on an AWS S3 Volume, this means that Craft has to make a request for each transform to figure make sure it still exists.

On a page with 20 transformed images, not only this adds time, but this also counts toward requests and can increase site hosting costs.

[brandonkelly]

@andris-sevcenko Seems like locally-stored transforms are the main situation where this would be a concern to begin with. Maybe reconsider with the caveat that it will only affect local transforms?

Still adds extra I/O though, so not 100% advocating for it.

[msimpson]

@brandonkelly Yes, I was speaking in regard to locally-stored transforms. @andris-sevcenko In my mind, the catch would occur in (or around) craft\web\Request when a request fails.

So, while it wouldn't be a preemptive measure that continually creates undue load, I can understand the complexity of parsing the failed path in an attempt to discover whether it's a transformed asset.

However, it would be easier if the transform URI contained some parameters to aid in that identification, e.g. https://www.example.com/assets/_1920x1080_crop_center-center_70_none/1/example.jpg?assettransformindexid=1.

[andris-sevcenko]

@msimpson it's going to be a bit more simple and less ideal.

Here's how the transform thing works under the hood (so it doesn't seem like I'm just throwing words around):

• Template outputs an asset URL with transform parameters (this step is skipped if accessing API directly with code)
• Craft takes the asset and the transform parameters and figures out what the subfolder for that transform would be
• Craft checks whether an entry exists for such a transform in the transform index. If it does not - Craft generates a new transform and creates an entry in the index for it.
• Craft returns an URL based on the volume, asset, and the subfolder listed in the transform index.
• Browser makes the request to the URL.

So, as you see, there's really nothing to wrap around when a request fails - that is entirely up to the browser to request that URL and get the file or the 404

So, there's no simple solution to figure out whether a transform needs to be regenerated after the URL has been generated, however, it's easy to check whether a file exists before generating the URL. It's just expensive for remote volumes.

[andris-sevcenko]

I just pushed this change for 3.5. Note, that this will affect only local volumes.