Clear resized images on asset replace - good idea?

[hiasl]

I'm submitting a...

• general question

Steps to reproduce

Our editors just complained that when they do a "Assets > any image > replace file" with another asset with the same filename, the resized images do not get regenerated. I checked that and they are right, since the default transformation string does not respect a file's mtime.

So we now modify it in a config/imager-x.php to

'filenamePattern' => '{basename}_{transformString|hash}_{timestamp}.{extension}'

This does the job, but I was wondering if it is generally a good idea to keep resized images when the content of the file changes (or in other words, when someone replaces the file with a different binary). My initial idea would be to simply delete the folder which is named by the assets's ID in the resized image path, that would automatically clear all resized images of the replaced image binary.

My thoughts:

• Pro: Old images would immediately be removed
• Con: Cached pages could contain references to removed files / dirs. This could be especially a problem if you use static caches which might not get cleared immediately.

What are your thoughts on this?

• Craft version: 4.13.1.1
• PHP version: 8.2
• Imager-X: 4.4.1

[aelvan]

Hi,

The Imager cache is actually supposed to be deleted when a file is replaced, so I'll have to check if there's a bug there if that wasn't happening for you. But, what OS is this on (or, where did you test and confirm that it was not deleted), and you're using the local "craft" transformer right?

[hiasl]

Hi,
yes, we are transforming locally!

This is the setup where I tested:
PHP version 8.2.13
OS version Linux 4.18.0-553.22.1.el8_10.x86_64
Database driver & version PostgreSQL 12.18
Image driver & version GD 8.2.13
Craft edition & version Craft Pro 4.13.1.1
Blitz 4.23.7
Imager X 4.4.1

I did the following:

• on the Linux console I monitored the directory where imager-x saves its resized files for a certain asset ("watch ls -ahl ")
• in a second window I watched a directory where Blitz Cache saves its static pages
• then I replaced the asset with a different image but the same filename
  What happened:
• Blitz cache recognized the modified image and deleted its static version of the page
• The did not get deleted, the resized images and the directory were not removed
• on the next browser request to the entry using the asset, Craft re-rendered the page and Blitz cache recreated its static content (therefor the resizing mechanism should have worked).
• but (since the directory was not deleted), the image was still the old one, not the replaced one

one more note: Both the source and the resized images are on an NFS share. To make sure, file permission are not the root of this problem, I su'ed into the user of the webserver and tried to delete such a directory on the console, this worked.

[aelvan]

Hi, I tested this, and transformed images are still deleted when replacing files.

The folder you're looking at with the transformed images, does it contain the ID for the image? Ie, is it <imagerSystemPath>/<volume>/<path_to_asset>/<id_of_asset>/...?

[hiasl]

I just checked this and it is exactly as you describe it. AND it contains the ID.

Would it be a good idea that you send me a filename and line where this magic happens so that I can simply do a quick
die('image-x should delete here')
to see if we reach that point the the case of an image replacement and make further checks. imager-x version is 4.4.1

I also again checked permissions, but they are 777 and owned by the webserver.

[aelvan]

Sure. The event listener that should get triggered is on line 241 in src/ImagerX.php. It runs removeTransformsForAsset() in src/services/ImagerService.php where the actual code is.

I forgot to ask, did you check your logs for any errors? removeTransformsForAsset() should log various errors if it can't clear the directory.

But first maybe try to establish if the event listener is triggered at all. Did you try disabling Blitz? Maybe we're listening for the same event and one of the plugins mucks it up for the other somehow? Shouldn't be an issue but worth checking.

[hiasl]

sorry for the delay, please keep this open