Broken image tags when image is changed with rendition caching enabled
See original GitHub issueIssue Summary
With rendition caching enabled, changing an image results in broken image tags (old file paths remain cached).
Steps to Reproduce
- Start a new project with
wagtail start myproject
- Enable rendition caching
- Edit home/models.py as follows
from django.db import models
from wagtail.core.models import Page
from wagtail.images.edit_handlers import ImageChooserPanel
class HomePage(Page):
image = models.ForeignKey(
'wagtailimages.Image', on_delete=models.SET_NULL, related_name='+', null=True, blank=True
)
content_panels = Page.content_panels + [
ImageChooserPanel('image')
]
- Edit home/templates/home/home_page.html as follows
{% extends "base.html" %}
{% load static wagtailimages_tags %}
{% block content %}
{% image page.image width-200 %}
{% endblock content %}
- Open the page in the frontend, ensure the rendition is cached
- Change the image in the Wagtail admin (Change image file)
- Reload the page from step 5, a broken image tag is now rendered because an old image path is still cached
I would expect the cache to be cleared when the image is changed.
- I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: no
Technical details
- Python version: 3.8.2
- Django version: 3.0.5
- Wagtail version: 2.9.0
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (2 by maintainers)
Top Results From Across the Web
Dispatcher caching issue while displaying ... - Adobe Support
If the image is first accessed from the mobile devices, then Untitled.jpg folder is created to cache the renditions image. Rendition images are ......
Read more >publishing site - Image renditions not working anymore
1 Answer 1 ... Image Renditions will work if you first flush the blob cache and then do IISRESET (otherwise it will still...
Read more >Image rendition issues in SharePoint on premise related to ...
Images do not load properly or load with full size that is without rendition. This can happen if Blob Cache is corrupted on...
Read more >Angular: caching of images when using img ng-src in firefox ...
I used to use jQuery DOM manipulation (insertion of <img> tags) to show different images based on what the user clicked, and recently...
Read more >Dispatcher caching issue while displaying the image ...
We are using the image renditions to display the images for different devices in Adobe Experience Manager(AEM). The HTML5 Adaptive image is used ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thank you very much for the report and investigations, @pascalw. I’m sorry for introducing this bug.
I think the cache key can be made robust enough by including the file hash, i.e.:
I’ve tested this successfully with file and focal point changes.
@tomdyson no need to apologize for bugs! (https://blog.danslimmon.com/2019/08/02/stop-apologizing-for-bugs/)
I’m not sure though that only adding the
file_hash
to the cache key is a full solution. It indeed will work most of the time, but for example it doesn’t in this case:Now granted, this is a bit of an edge case but it’s annoying to recover from. Also if in the future new attributes or functionality are added to Images or Renditions, new scenario’s might be introduced where the cache is poisoned in a similar way.
What do you think about using signals to purge the cache when renditions are destroyed or updated? This seems pretty robust and cover all current and future cases, and we don’t have to add a column to the image table.
Something like this: