Opened 3 years ago

Closed 10 months ago

Last modified 8 months ago

#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: Guilherme Gondim <semente@…> Owned by: Johannes Hoppe
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 (22)

comment:1 Changed 3 years ago by Tim Graham

Component: contrib.admincontrib.staticfiles
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted

I haven't tested, but it seems like this should indeed work like you described.

comment:2 Changed 19 months ago by Eran Rundstein

Hi!
Any plan to do anything about this?
This is unfortunately still broken :(

comment:3 Changed 19 months ago by Tim Graham

It doesn't appear that anyone has offered a patch.

comment:4 Changed 18 months ago by antonpp

Owner: changed from nobody to antonpp
Status: newassigned

comment:5 Changed 12 months ago by David Sanders

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 Changed 11 months ago by Maxime Lorant

Cc: maxime.lorant@… added
Owner: antonpp deleted
Status: assignednew

comment:7 Changed 11 months ago by Maxime Lorant

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

Last edited 11 months ago by Maxime Lorant (previous) (diff)

comment:8 Changed 11 months ago by Johannes Hoppe

Cc: info@… 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 Changed 11 months ago by Claude Paroz

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 Changed 11 months ago by Johannes Hoppe

Owner: set to Johannes Hoppe
Status: newassigned

I agree. I'll look into it during the DUTH sprints.

comment:11 Changed 11 months ago by Collin Anderson

Cc: cmawebsite@… added

comment:12 Changed 11 months ago by Johannes Hoppe

Has patch: set

comment:13 Changed 11 months ago by Collin Anderson

(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:14 Changed 11 months ago by Claude Paroz

Should we lru_cache the static tag results?

comment:15 Changed 11 months ago by Johannes Hoppe

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.

Last edited 11 months ago by Johannes Hoppe (previous) (diff)

comment:16 Changed 10 months ago by Tim Graham

Patch needs improvement: set

Left some comments for improvement on the pull request.

comment:17 Changed 10 months ago by Johannes Hoppe

Patch needs improvement: unset

I hope I caught them all. Thanks Tim

comment:18 Changed 10 months ago by Tim Graham

Patch needs improvement: set

Left some more comments.

comment:19 Changed 10 months ago by Johannes Hoppe

Patch needs improvement: unset

Updated my PR

comment:20 Changed 10 months ago by Tim Graham

Triage Stage: AcceptedReady for checkin
Type: BugNew feature

Looks good pending incorporation of my edits.

comment:21 Changed 10 months ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In cf546e1:

Fixed #21221 -- Made form Media and static template tag use staticfiles if installed.

comment:22 Changed 8 months ago by Tim Graham <timograham@…>

In 20e2b22:

Refs #21221 -- Added test for legacy static usage in form Media.

Before cf546e1, static files in form or widget Media were usually
wrapped with contrib.staticfiles.templatetags.staticfiles.static.
This test ensures compatibility with third-party code that's still
using this pattern.

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