Opened 10 years ago

Closed 7 years ago

#22353 closed Bug (duplicate)

CachedStaticFilesMixin lags in updating hashed names of other static files referenced in CSS

Reported by: woodlee Owned by: Marc Egli
Component: contrib.staticfiles Version: 1.6
Severity: Normal Keywords:
Cc: cmawebsite@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Procedure to replicate:

  1. Be using staticfiles with CachedStaticFilesStorage.
  2. Have a CSS file such as 'abc.css' which refers to an image file such as 'xyz.png' (via either "url()" or "@import").
  3. Do an initial run of collectstatic. Observe correct substitution of the path to 'xyz.png' to its hashed name within abc.css.
  4. Change the contents of xyz.png (maybe it's a sprites file... so changes aren't unheard of!).
  5. Rerun collectstatic (without the --clear option).
  6. Observe that abc.css still refers to the old hashed name of xyz.png; this is the bug.
  7. Run collectstatic a third time.
  8. Observe that abc.css now refers to the correct, newer hashed name of xyz.png.

I believe this is happening because during post_process, when the url_converter calls url() (see https://github.com/django/django/blob/1.6.2/django/contrib/staticfiles/storage.py#L195), url() gets the hashed name out of the staticfiles cache... which has not yet been updated with the new hashed-name value for the image file, since said cache updating doesn't happen until the end of post_process.

I think the best solution may be to add a kwarg of 'use_cache=True' to url(), which url_converter can set to False when it calls url(). When False, the cache will simply be evaded (not updated) and hashed_name can be called directly. In this way, url_converter is always substituting to the most up-to-date hash, but actually updating the cache is still delayed until the end of post_process, which seems desirable since I think updating that cache should happen as closely as possible in time to the moment when the new static assets are placed wherever they'll be served from (bit of a race condition, there).

Unrelated: it would be nice to warn in documentation that if you define a separate 'staticfiles' cache in CACHES, it might be desirable to set its TIMEOUT option to None. I kept wondering why lookups were coming back empty and eventually realized it was because my staticfiles cache was using the default 5 minute timeout.

Change History (7)

comment:1 by Marc Egli, 10 years ago

Owner: changed from nobody to Marc Egli
Status: newassigned

comment:2 by Marc Egli, 10 years ago

Easy pickings: unset

I am removing the easy pickings because there are more complex problems involved in this ticket. We need to make sure that in this case the image is always post-processed before the css file that is referring to it. This also applies to css files including other css files.

comment:3 by Marc Egli, 10 years ago

Has patch: set
Triage Stage: UnreviewedAccepted

comment:4 by Tim Graham, 10 years ago

Patch needs improvement: set

The new test on the PR doesn't pass.

comment:5 by Collin Anderson, 9 years ago

Cc: cmawebsite@… added

comment:6 by Collin Anderson, 9 years ago

#24452 is very similar (CSS hash not changing).

comment:7 by Ed Morley, 7 years ago

Resolution: duplicate
Status: assignedclosed

This appears to be a dupe of #24452 and friends, and so should be fixed in Django 1.11.

Note: See TracTickets for help on using tickets.
Back to Top