Cropped images are not recreated if deleted during runtime about django-versatileimagefield HOT 5 CLOSED

Hey @Syberspace !

It seems like both this issue and #25 stem from a need to be able to delete the renditions (and their associated cache entries) associated with an image file when that image file is deleted. This is a feature I knew I'd ultimately have to implement but kept pushing to the back burner in favor of squashing bugs or tightening up other features on the project.

IRT to your possible fix, 'Recreate sizer/filter result file if not present on the filesystem': At the surface what you're suggesting makes sense but if I implemented it I'd be hobbling the current cache architecture. VersatileImageField will create cache entries each time it makes an image thereby providing a performance increase the next time that image rendition is accessed (in short: your app doesn't have to check the file system if it finds a URL in the cache). If the image file associated with a cache entry is deleted (without also clearing that cache entry), you will get 404's (since the field isn't actually checking the file system every time).

I started implementing a reliable chain of rendition/cache deletion this morning but probably won't have it completed this week. Here's a few options of what you could do in the meantime:

1. Ditch the functionality of having a user's avatar image filename be identical to their username (i.e. have the name of the uploaded file be the name of their avatar image). This is the quickest, simplest solution.
2. Append the file's unique md5 hash as a suffix to a user's profile image. Example: If you have a user named 'foobar' their profile image would look something like 'foobar-2a53375ff139.jpg'. This will ensure unique files have unique names while keeping a user's username included in the profile image. (FWIW: This is my recommended solution...check out this answer on SO for more info about how to get a file's md5 hash.)
3. Write a pre_save signal that checks the file hash of a user's currently-saved avatar image and compare it against the about-to-be-saved one. If they're different, manually delete both the image renditions and their cache entries that have been created prior to saving the new image (where in your immediately create them). This solution is a bit 'duct tapey' and brittle (since adding in a new image rendition on your project necessitates updating your signals). IMHO, option 2. above is a lot more elegant and future-proof.

I hope this info helps!

from django-versatileimagefield.

Thanks for this change. Just less than day ago I noticed a need for this kind of feature too and was surprised to see that just 18 hours ago the change was merged into master. Very much appreciated.

from django-versatileimagefield.

Hey @LunarSweeper !

It's not quite merged into master yet (it's still in the delete-renditions branch). It won't be long until this featured is released, just need to do some minor code-cleanup and flesh-out some documentation on how to use the new rendition deletion and cache-clearing API. Once that's done I'll get it released to PyPI ASAP.

Stay tuned!

from django-versatileimagefield.

Thanks. Any estimate about the release schedule so we can plan our own deliveries accordingly?

from django-versatileimagefield.

Hey @Syberspace and @LunarSweeper –

I just published the rendition cache-clearing and deletion code in the 1.3 release on PyPI, you can get it by running the following command:

$ pip install django-versatileimagefield==1.3

Here's a link to the docs about how to leverage this new functionality.

Please don't hesitate to reach out if you have any difficulty getting it working!

from django-versatileimagefield.