Set up data in custom Django context processors to access on all Django templates

Problem

You want to set up data to become available on all Django templates, without having to set up the data individually on Django view methods.

Solution

Create a custom Django context processor method. Add the custom Django context processor method to the context_processors variable in OPTIONS of the TEMPLATES variable of a project's settings.py file. Use standard Django template syntax to gain access to the data exposed by the custom Django context processor method.

How it works

Unlike data set up in Django view methods or url extra options where data is only available on individual Django templates, custom Django context processor methods allow you to set up data for access on all Django project templates.

A custom Django context processor method is just like a regular Python method with an HttpRequest object argument that returns a dictionary. Where the returning dictionary keys represent template references and the values data objects (e.g. strings, lists, dictionaries) to be exposed on the template. Listing 1 illustrates a custom Django context processor method.

Listing 1 - Custom Django context processor method

def onsale(request):
    # Create fixed data structures to pass to template
    # data could equally come from database queries
    # web services or social APIs
    sale_items = {'Monday':'Mocha 2x1','Tuesday':'Latte 2x1'}
    return {'SALE_ITEMS': sale_items}

As you can see in listing 1, the onsale method in listing 1 has a request argument -- which is the HttpRequest object -- and returns a dictionary. The dictionary in this case has a single key called SALE_ITEMS and a value which is a hard-coded dictionary. However, just as you could set up any type of data from a Django view method to pass to a template, a custom Django context processor method can also access any data you wish to be made available to a template.

The custom context processor method can be placed inside any project file or directory. The location and naming conventions are of little importance, because Django detects context processors through the context_processors variable in OPTIONS of the TEMPLATES variable of a project's settings.py file. To keep things organized I'll place the method in listing 1 inside a file called processors.py in the stores app sub-directory.

Once you save the custom context processor method, you have to configure Django to locate it. Listing 2 shows the context_processors variable to activate the custom context processor method.

Listing 2 - Django template context processor definitions in context_processors in OPTIONS of TEMPLATES

        'OPTIONS': {
            'context_processors': [
                'coffeehouse.stores.processors.onsale',
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
	 }

In listing 2 you can see the coffeehouse.stores.processors.onsale declaration in the context_processors list. The first part coffeehouse.stores represents the package.app name, processors is the file that contains the custom context processor (i.e. processors.py inside the stores app) and onsale is the actual method that contains the custom context processor logic.

The remaining values specified in the context_processors list are Django's default context processors. These last context processors expose general purpose application data to all templates.

Once you declare the context_processors illustrated in listing 2 on you project's settings.py file, the custom dictionary with the SALE_ITEMS key in listing 1 becomes available to all Django templates.