I'm not sure what the difference is, it seems like both of them are working. I googled around, and seems like they are pretty much same thing.
Just out of curiosity, which one do people use in the field?
I read that but still don't know when to use which, and which one people in the field use. Mine works for both of them. At first I thought it's loading static folder but it works for staticfiles too... –
For the moment (Django 1.9 and earlier), {% load staticfiles %} loads the static templatetag from the contrib app that has more features than the built-in django.core.static.
The most important difference is staticfiles can manage files stored on CDN, since its resolver can manage hashes for example. core.static only append STATIC_URL to the static filename, which is not enough if you're processing your files (e.g. adding md5 hash to clear cache between releases)
This difference is due to the fact that managing non-local storage files was not dedicated to be included in the core package of Django, but was still useful to many developers to be implemented as a official contrib package. So if you started to use staticfiles, you had to remember to use it every in your templates. BUT, some problems could appear, for example when using Media classes so the decision has been to merge those two templatetags into one and use a different behaviour whether the developer has django.contrib.staticfiles in its INSTALLED_APPS or not.
From Django 1.10 and onwards (also see ticket in Django tracker), the {% load static %} is going to use staticfiles internally if activated (oherwise keep default behaviour), and the templatetag in the contrib package will be deprecated to avoid confusion.
TL;DR
Before Django 1.10: staticfiles loads a templatetags that can manage non-local storage where static can't (or not easily) ;
From Django 1.10: contrib.staticfiles app still exist but its templatetags will be removed only the {% static %} templatetags remains ;
From Django 2.0 (I believe): {% load staticfiles %} is removed.
For now, use staticfiles templatetags if you use the related contrib app (and you know why you are using it) until Django 1.10, otherwise just use static.
just an interesting piece of code inside the 'django/contrib/staticfiles/templatetags/staticfiles.py' about this topic:
import warnings
from django import template
from django.templatetags.static import (
do_static as _do_static, static as _static,
)
from django.utils.deprecation import RemovedInDjango30Warning
register = template.Library()
def static(path):
warnings.warn(
'django.contrib.staticfiles.templatetags.static() is deprecated in '
'favor of django.templatetags.static.static().',
RemovedInDjango30Warning,
stacklevel=2,
)
return _static(path)
#register.tag('static')
def do_static(parser, token):
warnings.warn(
'{% load staticfiles %} is deprecated in favor of {% load static %}.',
RemovedInDjango30Warning,
)
return _do_static(parser, token)
so ill dare to assume {% load staticfiles %} is going to be removed after the django 3 release :)
Related
I am using Django 3, the latest version. I have defined the static files directories properly as required.
Currently to display an image, both the following source codes work fine.
Code 1:
<img src="static/img/logo.png">
Code 2:
{% load static %}
<img src="{% static 'img/logo.png' %}">
Since both the code snippets are working and running fine without any problems, I am wondering why not to simply use the way of Code 1 above and refrain from the extra lines of Code 2.
Which one would be beneficial and why? Please guide.
The base/master level templates would work without static tag and maybe considered for performance.
However for other level templates either nested or in app templates or nested urls, it's required to be reference with static as it would minimise chances of error. So for all other templates it is recommended to use static tag.
I've been using {% get_media_prefix %} for a very long time. I was explaining this to someone when he pointed this out.
Why do I need to declare {% load static %} in order to use it?
It even uses in the documentation's example code here.
To an extent I understand that static files and media files are similar in nature. Even when we use them with combination of nginx+gunicorn, nginx handles both of them(we let everything else proxy, but not these).
But still we have a separate MEDIA_URL and STATIC_URL as well as MEDIA_ROOT and STATIC_ROOT defined for these files.
Then why {% load static %} needs to be declared in order to use {% get_media_prefix %} ?
Thanks in advance.
In order to use a template tag in your HTML you must first load the module that contains it.
So, accorrding to the source code of get_media_prefix template tag, this template tag lives inside django/templatetags/static.py.
That's why you have to load it every time you use it, in every HTML template.
This, of course, applies to every template tag usage. At the top of every HTML file you load the template tags and then you use them. Just like you import a function in your python code.
UPDATE: From the Django 1.3 release notes:
In previous versions of Django, it was common to place static assets in MEDIA_ROOT along with user-uploaded files, and serve them both at MEDIA_URL. Part of the purpose of introducing the staticfiles app is to make it easier to keep static files separate from user-uploaded files. Static assets should now go in static/ subdirectories of your apps or in other static assets directories listed in STATICFILES_DIRS, and will be served at STATIC_URL.
As you can see, Django used to treat both static and media the same. Since Django 1.3 this changed, but the template tag not. No big deal. It's just a convention.
In django I'm curious concerning the {% load staticfiles %} template directive.
In static files I have a sass directory, and sass in turn can have a cache which gets quite large. I'm not inquiring of 'best practice' though, but in any case are all files pre-loaded or not?
If I'm only using, for instance, fonts, bootstrap, a personal stylesheet, etc...is it going to load all the things I'm not using?
Very curious about this. I don't want to use up more resources than needed.
You've completely misunderstood what the load tag does. All it does is make a template tag library available for the template to use: in this case, the "staticfiles" library which includes the definition of the {% static %} tag. Without that load statement, you can't use that tag.
It doesn't do anything with the staticfiles itself - indeed it can't, loading them is a matter for the browser, which will do whatever is in your HTML.
I am attempting to override/extend the header for the Django admin in version 1.2.1. However when I try to extend the admin template and simply change what I need documented here: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-vs-replacing-an-admin-template), I run into a recursion problem.
I have an index.html file in my project's templates/admin/ directory that starts with
{% extends "admin/index.html" %}
But it seems that this is referencing the local index file (a.k.a. itself) rather than the default Django copy. I want to extend the default Django template and simply change a few blocks. When I try this file, I get a recursion depth error.
How can I extend parts of the admin? Thanks.
SOLUTION: Rather than extending, I copied the files into my_templates_directory/admin/ and just edited them as I wished. This solution was acceptable, though not ideal.
The contrib/admin/templates/admin path needs to go before the directory with your custom admin templates in your list of paths in TEMPLATE_DIRS in your settings.py
Create a symlink to contrib/admin/templates/admin/ in your templates directory and use it in your {% extends %} statement.
cd /path/to/project/templates/
ln -s /path/to/django/contrib/admin/templates/admin/ django_admin
Now in your admin/index.html use {% extends "django_admin/index.html" %}
EDIT: Just realized that you're on windows... Not sure how to achieve the same results. Hopefully this still helps the folks on linux.
SOLUTION: Rather than extending, I copied the files into my_templates_directory/admin/ and just edited them as I wished. This solution was acceptable, though not ideal.
I'm working with a Satchmo installation that resides within an existing project. This project has its own templates as well as templates for some of the various apps that are installed. Some of these app-specific templates have their own app_base.html variations that expect to derive form base.html. I'd like to be able to do the same thing with my Satchmo templates and have them reside within my project's base, but also have some additional html added around all of them.
/templates
base.html
index.html
/news
news_base.html (extends base.html and adds news-specific template features)
index.html
detail.html
/store
base.html (overriding Satchmo's base)
This structure works somewhat, but not how I expected. in /store/base.html (Satchmo's base) I've simply replaced everything with a test message. I can see the message, so I know satchmo is loading its base and not the site's base. However, I can't extend my project's base anymore since using:
{% extends "base.html %}
Yields a recursion error since its calling itself and the following simply won't work.
{% extends "../base.html" %}
I realize that I can change my project's base.html to a slightly different name and point all app-specific templates at them, but it seems like a pretty major hack on such a fundamental aspect of the template structure.
Hmm, I didn't think django looked up templates relatively like that.
Kinda crazy hack, but this should work:
/templates/store/base.html extends "global_base.html"
/templates/global_base.html extends "base.html"
Depending on how you have your template structure set up, it might also be a good idea to play with the settings.TEMPLATE_LOADERS variable.
TEMPLATE_LOADERS Default:
('django.template.loaders.filesystem.load_template_source',
'django.template.loaders.app_directories.load_template_source')
A tuple of callables (as strings) that
know how to import templates from
various sources. See The Django
template language: For Python
programmers.
For more information on how this affects the template loading process:
http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types
From the way you describe your problem, it seems like by commenting out the "app_directories.load_template_source" file line, you might be able to better find a way to accomplish what you're doing.
django.template.loaders.app_directories.load_template_source
Loads templates from Django apps on
the filesystem. For each app in
INSTALLED_APPS, the loader looks for a
templates subdirectory. If the
directory exists, Django looks for
templates in there.
This means you can store templates
with your individual apps. This also
makes it easy to distribute Django
apps with default templates.
For example, for this setting:
INSTALLED_APPS = ('myproject.polls',
'myproject.music') ...then
get_template('foo.html') will look for
templates in these directories, in
this order:
/path/to/myproject/polls/templates/foo.html
/path/to/myproject/music/templates/foo.html
Note that the loader performs an
optimization when it is first
imported: It caches a list of which
INSTALLED_APPS packages have a
templates subdirectory.
This loader is enabled by default.
I just had this same problem. It looks like the satchmo developers planned for this by putting an "empty" base in the shop template directory. While this may not be relevant to you anymore, I would have like to have seen this here.
You can make a "shop" directory in your template directory and copy the main satchmo base.html to that directory.
This worked for me.