Make context processor run outside of RequestContext

[Anthony King]

Not all templates are generated within the context of a request, such as email rendering.
This prevents you accessing variables that are set in your context processors.

In our codebase, we pass in some settings and other constants via a context processor, which never looks at the request object.

It would be convenient for those constants to be used in all templates, as apposed to templates with requests only.

I see 2 possible approaches to adding this functionality:

• Add a constant_processor, however this wrongly limits it to constants.

• make the request argument optional going forward, and use arg inspections to conditionally context processors for a period.

Using some_context_processor(request=None) would show the processor supports request objects not being set.

[Aymeric Augustin]

Quoting myself or #django-dev:

I would be more happy to support an option to add globals to Django templates — that could be a simple configuration option — than to start executing request context processors without a request

for your own projet, you can create a custom template backend that inherits the Django template backend, overrides render, and adds your globals to the context before calling the parent

[Tim Graham]

Is adding another way to do this better than using a template tag? You could add the tag to TEMPLATES['OPTIONS']['builtins'] to avoid {% load ... %} in the template.

[Tim Graham]

Feel free to reopen with an explanation of why the solution I proposed isn't sufficient.