#21221 closed New feature (fixed)
Widgets and Admin's Media should use the configured staticfiles storage to create the right path to a file
Reported by: | Owned by: | Johannes Maron | |
---|---|---|---|
Component: | contrib.staticfiles | Version: | 1.5 |
Severity: | Normal | Keywords: | staticfiles, admin, CachedFilesMixin, media, widgets |
Cc: | maxime.lorant@…, info@…, cmawebsite@… | 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
Taking for example the following widget snippet:
class Editor(widgets.Textarea): class Media: js = ('editor/editor.js',) css = {'all': ('editor/editor.css',)}
When using CachedFilesMixin, from the staticfiles contrib app, the right path to the media file should be the one with the hash suffix but what we got is just a concatenation of STATIC_URL and the relative path of the media file.
Change History (25)
comment:1 by , 11 years ago
Component: | contrib.admin → contrib.staticfiles |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 10 years ago
Hi!
Any plan to do anything about this?
This is unfortunately still broken :(
comment:4 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 9 years ago
Many of the admin forms in Django mainline get around this by manually using the django.contrib.admin.templatetag.admin_static.static
template tag when specifying the filename, although this has disadvantages. See #25553 regarding the need for a lazy version of the tag since the forms may be imported during the app registry process and try to evaluate the templatetag too early (before collectstatic
has run).
It's also tricky to have a subclass override one of the form assets if the filename changes, requiring it to use the static version of the filename to ensure it matches in all cases.
Off the top of my head (without thinking too deeply about it), it seems like the change would fit best in the rendering process for the Media widget? This is where the simple logic of prepending the STATIC_URL
occurs so it seems logical to do the transformation here, and also leaves the filenames as their untransformed version up until the actual rendering. Specifically seems like it would fit in the absolute_path
method here.
comment:6 by , 9 years ago
Cc: | added |
---|---|
Owner: | removed |
Status: | assigned → new |
comment:7 by , 9 years ago
No patch from antonpp in seven months, so I allowed myself to set this ticket to new again. Solution proposed by dsanders seems fine, but I think we should be cautious and not re-process the URL at each page/template generated (the static URL should not changed in time, unless we call collectstatic
)...
For information I got the same problem when using a third-party library (django-select2) in a project using a CDN that add a hash suffix to statics : https://github.com/applegrew/django-select2/issues/221#issuecomment-153666276
comment:8 by , 9 years ago
Cc: | added |
---|
I agree this is an issue. It is ether poorly documented that form media behaves different than static files or the behaviour is just wrong.
I'd very much like to clarify that, before making any changes to django-select2
. If this is in deed wrong behaviour and not a documentation issue, I can work on this on the DUTH sprints.
comment:9 by , 9 years ago
I did some experiments with this, leading to https://github.com/claudep/django/commit/2f5c6892523e80d57f9b50bb7bc2e5dcfc07426b
But I'm afraid this suffers from the re-processing load mentioned in comment:7.
comment:10 by , 9 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
I agree. I'll look into it during the DUTH sprints.
comment:11 by , 9 years ago
Cc: | added |
---|
comment:12 by , 9 years ago
Has patch: | set |
---|
comment:13 by , 9 years ago
(If we don't like the contrib import from core, and alternative could be to move the necessary code into core #25689). In this case I think it's ok.
comment:15 by , 9 years ago
I wouldn't. I don't see a big performance opportunity, but the risk that someone wants to manipulate the storage during runtime.
We could rather cache the storage.url method.
I added a second commit that should clean up a little.
comment:16 by , 9 years ago
Patch needs improvement: | set |
---|
Left some comments for improvement on the pull request.
comment:20 by , 9 years ago
Triage Stage: | Accepted → Ready for checkin |
---|---|
Type: | Bug → New feature |
Looks good pending incorporation of my edits.
I haven't tested, but it seems like this should indeed work like you described.