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