When an image style is edited, the old, stale images are visible for up to 2 weeks (the default expires header).
Expected result: a desaturated image.
Actual result: the original image.
The problem can be observed without any proxies or caches, but is particularly troublesome when an HTTP cache is in use. Some services like CloudFront don't support directory purges, so it's difficult to invalidate the old images.
The issue is also an obstacle to raising the default expires value (YSlow's definition of "far future" is up to ten years).
Add a query string in image_style_url().
The current patch uses a timestamp of when the style was saved, but an alternative would be a hash of the style's config data.
The advantage of the timestamp is no extra CPU work is needed to compute a hash. A hash would be more merge-friendly for VCS, since it doesn't need to be stored in the yml file.
patch needs review
N/A
N/A
I am displaying some images with theme('image_style').
Even if the image is changed, it is being cached on browsers and they are forced to hit CTRL-F5 for it to update. Is Drupal core doing anything to counter this? (e.g. timestamps after the image filename)
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1514760.patch | 6.17 KB | grendzy |
| #5 | 1514760.patch | 2.04 KB | grendzy |
| #3 | 1514760.patch | 2.06 KB | grendzy |
Comments
Comment #1
fenda commentedSo it looks like this isn't in core. I'm adding REQUEST_TIME to the end of the image path to force a browser cache refresh.
However, for example, image.png?123 is writing as image.png%3F123 in DOM.
Any ideas how to fix the question mark being encoded?
Comment #2
grendzy commentedIt should be possible to hash the effects settings, and add that as a query string:
image_styles()uses a static cache so calls toimage_style_load()(needed to get the effects settings I think) would not be expected to add extra database overhead.Considering that Drupal automatically purges the directory when the form at
admin/config/media/image-styles/edit/%styleis submitted, it seems clear the intention is to update existing files so I think the caching problem is a bug.Comment #3
grendzy commentedComment #5
grendzy commentedComment #7
grendzy commentedComment #8
grendzy commentedClarifying the title slightly: The path component of the URL wouldn't change with this patch, so old links (even with a stale query string) keep working.
Comment #8.0
grendzy commentedadd template
Comment #8.1
grendzy commentedfar-future
Comment #8.2
grendzy commentedtypo
Comment #15
steven jones commentedWe already have a query string that works as a cache buster on image derivatives: the itok security token in the URL, so this could be expanded to add in a hash of the config of the image style.
Comment #16
steven jones commentedSome thoughts:
However, a lot of web servers will allow client browsers to cache static assets like images for a decent length of time, without revalidation and a lot of CDNs, Varnish etc will be configured to cache based on the URL with a long cache expiration time.
flushed for all images.flushed (ideally this would only bust the cache of this single image)A cache buster could be as simple as a monotonically increasing integer that's incremented on the above events, and simply added to the URL generated. The last event in the list above would cause a lot of unnecessary cache busting on a site where derivative flushing was common, and thus high cache misrates on downstream caches etc. But that might be acceptable for most sites.
Comment #21
krzysztof domański