Built-in context processors
By default, Django templates are enabled to have access to various variables. This eliminates the need to constantly declare widely used variables in every single Django view methods or as url extra options. These variables are made available through template context processors.
Django template context
processors are explicitly defined in a project's
settings.py
file, in the TEMPLATES
variable inside the OPTIONS
key. By default and as
illustrated in listing 3-1, Django projects are enabled with four
context processors built-in to Django. Next, I'll describe the data
variables made available by each of these context processors.
Django debug context processor (django.template.context_processors.debug)
The Django debug context processor exposes variables that are helpful for debugging. This context processor makes the following variables available on all Django templates:
debug
.- Contains True or False, based on theDEBUG
variable in thesettings.py
file.sql_queries
.- Contains the database connection details (e.g. SQL statements) run by the backing method view.
Note The Django debug context processor displays variable values only if the requesting IP address is defined in the INTERNAL_IPS variable in settings.py. Even if the variables are declared in a template (e.g.{{debug}} or {{sql_queries}}) this restriction permits that only certain users view the debug messages in the template, while other users won't view anything.
For example, to view the debug and sql_queries values on your local workstation, add INTERNAL_IPS = ['127.0.0.1'] to the settings.py file. This tells Django to display these variables values for requests made from the IP address 127.0.0.1
Django request context processor (django.template.context_processors.request)
The Django request context
processor exposes variables related to a request (i.e. HTTP
request). This context processor makes data available through a
massive dictionary named request
, which includes some
of the following key-values:
request.GET
.- Contains a request's HTTP GET parameters.request.POST
.- Contains a request's HTTP POST parameters.request.COOKIES
.- Contains a request's HTTP COOKIES.request.CONTENT_TYPE
.- Contains a request's HTTP Content-type header.request.META
.- Contains a request's HTTP META data.request.REMOTE_ADDR
.- Contains a request's HTTP remote address.
Django auth context processor (django.contrib.auth.context_processors.auth)
The Django auth context processor exposes variables related to authentication logic. This context processor makes the following variables accessible in Django templates:
user
.- Contains user data (e.g. id, name, email, anonymous user).perms
.- Contains user app permissions (e.g. True, False or explicit app permissions a user has access to in adjango.contrib.auth.context_processors.PermWrapper
object).
Django messages context processor (django.contrib.messages.context_processors.messages)
The Django messages context processor exposes variables related to the Django messages framework, introduced in chapter 2. Messages are added in Django view methods to the message framework, which are then exposed in Django templates. This context processor makes the following variables accessible in Django templates:
messages
.- Contains the messages added through the Django messages framework in Django view methods.DEFAULT_MESSAGE_LEVELS
.- Contains a mapping of the message level names to their numeric value (e.g.{'DEBUG': 10, 'INFO': 20, 'WARNING': 30, 'SUCCESS': 25, 'ERROR': 40}
).
Other built-in Django context processors: i18n, media, static, tz & CSRF context processors
The previous context processors offer some of the most common data required across all Django project templates, which is why they're enabled by default. However, this doesn't mean they are the only built-in Django context processors. There are in fact five more built-in context processors you can use to access certain data from all Django templates.
Django i18n context processor (django.template.context_processors.i18n)
The Django i18n context processor exposes variables related to internationalization logic. This context processor makes the following variables accessible in Django templates:
LANGUAGES
.- Contains available languages for Django projects.LANGUAGE_CODE
.-Contains the project language code, based on theLANGUAGE_CODE
variable in thesettings.py
file.LANGUAGE_BIDI
.-Contains the current project language direction. It's set toFalse
for left-to-right languages (e.g. English, French, German) orTrue
for right-to-left languages (e.g. Hebrew, Arabic).
Django media context processor (django.template.context_processors.media)
The Django media context processor exposes a variable related to media resources. This context processor makes the following variable accessible in Django templates:
MEDIA_URL
.- Contains the media url, based on theMEDIA_URL
variable in thesettings.py
file.
Django static context processor (django.template.context_processors.static)
The Django static context processor exposes a variable related to static resources. This context processor makes the following variable accessible in Django templates:
STATIC_URL
.- Contains the static url, based on theSTATIC_URL
variable in thesettings.py
file.
Tip Even though the static context processor is accesible (i.e. it's not deprecated) its functionality is outdated and should be avoided. You should use the staticfiles app instead. More details are provided in Chapter 5 in the section on setting up static web page resources (Images, CSS, JavaScript).
Django tz context processor (django.template.context_processors.tz)
The Django tz context processor exposes a variable related to a project's time zone. This context processor makes the following variable accessible in Django templates:
TIME_ZONE
.- Contains a project's time zone, based on theTIME_ZONE
variable in thesettings.py
file.
Django CSRF context processor (django.template.context_processors.csrf)
The Cross Site Request Forgeries
(CSRF) context processor adds the csrf_token
variable
to all requests. This variable is used by the {% csrf_token
%}
template tag to protect against Cross Site Request
Forgeries.
Although you can gain access to
the csrf_token
variable value in any Django template,
you will have little -- if any -- need to expose it directly, as
it's used as a security mechanism to detect forged requests.
Chatper 6 covering the topic of Django forms describes what is and
how CSRF works with Django.
Due to the security significance
of having the csrf_token
variable available on all
requests, the CSRF context processor is always enabled --
irrespective of the context_processors
list in
OPTIONS
-- and cannot be disabled.