Currently (Django 1.9 and earlier) {% load staticfiles %} loading the templateetag static from the Contrib application, which has more features than the built-in django.core.static .
The most important difference is that staticfiles can manage files stored on a CDN, since its recognizer can manage hashes, for example. core.static only adds STATIC_URL to the static file name, which is not enough if you are processing your files (for example, adding an hdd hash to clear the cache between releases)
This difference is due to the fact that managing non-local storage files was not intended to be included in the main Django package, but is still useful for many developers who need to be implemented as an official contribution package. Therefore, if you started using staticfiles , you had to remember to use it each in your templates. BUT, there may be some problems, for example, if using the Media classes , so it was decided to combine these two templatetags into one and use the other developer behavior django.contrib.staticfiles in his INSTALLED_APPS or not.
From Django 1.10 onwards (also see the Django tracker ticket ), {% load static %} will use staticfiles internally if it is activated (otherwise follow the default behavior), and the templatetag in the contrib package will become obsolete to avoid confusion.
TL; DR
- Prior to Django 1.10 :
staticfiles loads templatetags, which can manage non-local storage, where static cannot (or not easily); - From Django 1.10 :
contrib.staticfiles application still exists, but its templatetags will only be removed {% static %} templatetags remains; - From Django 2.0 (I believe):
{% load staticfiles %} has been removed.
Currently use staticfiles templatetags if you use the appropriate Contrib application (and know why you use it) before Django 1.10, otherwise just use static .
Maxime Lorant Dec 22 '15 at 20:33 2015-12-22 20:33
source share