Widgets and Admin's Media should use the configured staticfiles storage to create the right path to a file

[Guilherme Gondim <semente@…>]

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.

[Tim Graham]

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

[Eran Rundstein]

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

[Tim Graham]

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

[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.

[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

[Johannes Maron]

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.

[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.

[Johannes Maron]

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

[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.

[Claude Paroz]

Should we lru_cache the static tag results?

[Johannes Maron]

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.

[Tim Graham]

Left some comments for improvement on the ​pull request.

[Johannes Maron]

I hope I caught them all. Thanks Tim

[Tim Graham]

Left some more comments.

[Johannes Maron]

Updated my PR

[Tim Graham]

Looks good pending incorporation of my edits.

[Tim Graham <timograham@…>]

In cf546e1:

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

[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.

[Tim Graham <timograham@…>]

In a85e842:

Refs #21221 -- Prevented {% static %} tests from using contrib.staticfiles.

[Tim Graham <timograham@…>]

In 7d607127:

Refs #21221 -- Deprecated staticfiles and admin_static template tag libraries.

[Tim Graham <timograham@…>]

In 92d4d085:

Refs #21221 -- Removed staticfiles and admin_static template tag libraries.

Per deprecation timeline.