#24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash
when referenced media changes
-------------------------------------+-------------------------------------
Reporter: pmclanahan | Owner: nobody
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by pmclanahan):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> Steps to reproduce when using the Cached or Manifest staticfiles
> storages:
>
> 1. Have an image ({{{a.jpg}}}) and a CSS file that references this image
> in a {{{url()}}} call.
> 2. Run {{{collectstatic}}} and observe that copies of said files now have
> hashed names.
> 3. Change the content of {{{a.jpg}}} (the color was clearly wrong).
> 4. Run {{{collectstatic}}} again
> 5. Observe that {{{a.jpg}}} now has a new hashed name version
> 6. 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.
New description:
Steps to reproduce when using the Cached or Manifest staticfiles storages:
1. Have an image ({{{a.jpg}}}) and a CSS file that references this image
in a {{{url()}}} call.
2. Run {{{collectstatic}}} and observe that copies of said files now have
hashed names.
3. Change the content of {{{a.jpg}}} (the color was clearly wrong).
4. Run {{{collectstatic}}} again
5. Observe that {{{a.jpg}}} now has a new hashed name version
6. 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 [https://github.com/mozilla/bedrock/
mozilla/bedrock] (www.mozilla.org). More information may be added to
[https://bugzilla.mozilla.org/show_bug.cgi?id=1139606 the Mozilla bug
about this] as well.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24452#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.180c057ad3ef7a131dacbf8c0e8826cb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
