id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 18942 Documentation of `{% get_static_prefix %}` unclear Aymeric Augustin nobody "The [https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatetag-get_static_prefix documentation] says: > If you’re not using !RequestContext, or if you need more control over exactly where and how STATIC_URL is injected into the template, you can use the get_static_prefix template tag instead: ---- `{% get_static_prefix %}` was introduced in [33d8fcde8a]. It essentially returns `iri_to_uri(settings.STATIC_URL)`. The documentation implies that `{% get_static_prefix %}` is equivalent to `{{ STATIC_URL }}`. In theory it isn't, because the `static` context processor doesn't apply `iri_to_uri`, while the `get_static_prefix` tag does. I don't know if it matters in practice. Furthermore, I don't understand how `{% get_static_prefix %}` gives me ""more control"". I can see several ways to resolve this, the simplest would be: - also apply `iri_to_uri` in the `static` context processor (and in the `media` context processor) for consistency - simply state that `{% get_static_prefix %}` is an alternative to `{{ STATIC_URL }}` that doesn't require a context processor ---- There's also a built-in `{% static %}` tag, and another version provided by `contrib.staticfiles` since [1d32bdd3c9]. Having four different ways to achieve the same result — with various degrees of sophistication — is confusing. Is there a good reason to keep `{% get_static_prefix %}` and `{{ STATIC_URL }}`, if they do essentially the same thing? IOW is the ability not to use the `static` request context processor useful?" Cleanup/optimization closed Documentation dev Normal fixed Accepted 0 0 0 0 0 0