Opened 10 years ago
Last modified 7 years ago
#24452 closed Bug
Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes — at Version 1
Reported by: | Paul McLanahan | Owned by: | nobody |
---|---|---|---|
Component: | contrib.staticfiles | Version: | 1.7 |
Severity: | Normal | Keywords: | |
Cc: | David Sanders, Ed Morley | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Steps to reproduce when using the Cached or Manifest staticfiles storages:
- Have an image (
a.jpg
) and a CSS file that references this image in aurl()
call. - Run
collectstatic
and observe that copies of said files now have hashed names. - Change the content of
a.jpg
(the color was clearly wrong). - Run
collectstatic
again - Observe that
a.jpg
now has a new hashed name version - Obesrve that the CSS file refers to this new version, but the hashed name of the CSS file has not changed.
Because the CSS file's hash name was determined before processing the file's contents, changes in the referenced assets (images, fonts, etc.) will not result in a new hashed CSS file name. Thus when using a CDN and very long cache expire headers the CSS will never update, and the new version of the image will never be seen on the site.
We're currently working around this by making insignificant changes to the CSS whenever we need to make changes to only the content of referenced media, but this is error prone and clearly suboptimal.
This was observed in 1.6 using the CachedStaticFilesStorage
, but I testing in 1.7 as well. A fix could be backported to the 1.6 line should it come before 1.6 is unsupported and a patch release is desired.
Note: This was discovered in mozilla/bedrock (www.mozilla.org). More information may be added to the Mozilla bug about this as well.