Specifically in rendering shortcuts, template responses, and class-based
views that return template responses.
Also added a test for render_to_response(status=...) which was missing
from fdbfc980.
Thanks Tim and Carl for the review.
A deprecation path is required because the return type of
django.template.loader.get_template changed during the
multiple template engines refactor.
test_csrf_token_in_404 was incorrect: it tested the case when the
hardcoded template was rendered, and that template doesn't depend on the
CSRF token. This commit makes it test the case when a custom template is
rendered.
This is for consistency with Template.render.
It adds a little bit of knowledge about HTTP requests in
django.template.loader but I think consistency trumps purity.
This is the expected behavior, but given RequestContext's tortuous
implementation, a straightforward use of its API results in the
opposite.
This commits fixes a regression that must have happened at different
points in the multiple templates engine refactor for different features.
This avoids leaving projects silently vulnerable when this option is set
to a string instead of a one-item tuple containing that string, a very
common misconfiguration.
Previously, when a template was rendered with RequestContext, inclusion
tags were rendered with a plain context, losing additional information
available in the RequestContext.
The (admittedly bizarre) implementation of RequestContext.new() has the
side-effect of not running template context processors, making this
change backwards-compatible.
This commit changes the return type of these two functions. Instead of
returning a django.template.Template they return a backend-specific
Template class that must implement render(self, context).
Since this package is going to hold both the implementation of the Django
Template Language and the infrastructure for Multiple Template Engines,
it should be untied from the DTL as much as possible within our
backwards-compatibility policy.
Only public APIs (i.e. APIs mentioned in the documentation) were left.
Refs #7261 -- Made strings escaped by Django usable in third-party libs.
The changes in mark_safe and mark_for_escaping are straightforward. The
more tricky part is to handle correctly objects that implement __html__.
Historically escape() has escaped SafeData. Even if that doesn't seem a
good behavior, changing it would create security concerns. Therefore
support for __html__() was only added to conditional_escape() where this
concern doesn't exist.
Then using conditional_escape() instead of escape() in the Django
template engine makes it understand data escaped by other libraries.
Template filter |escape accounts for __html__() when it's available.
|force_escape forces the use of Django's HTML escaping implementation.
Here's why the change in render_value_in_context() is safe. Before Django
1.7 conditional_escape() was implemented as follows:
if isinstance(text, SafeData):
return text
else:
return escape(text)
render_value_in_context() never called escape() on SafeData. Therefore
replacing escape() with conditional_escape() doesn't change the
autoescaping logic as it was originally intended.
This change should be backported to Django 1.7 because it corrects a
feature added in Django 1.7.
Thanks mitsuhiko for the report.
Since RequestContext doesn't know its Engine until it's passed to
Template.render() -- and cannot without breaking a widely used public
API -- an elaborate hack is required to apply context processors.
Passed the engine instance to loaders. This is a prerequisite for
looking up configuration on the engine instance instead of global
settings.
This is backwards incompatible for custom template loaders that override
__init__. However the documentation doesn't talk about __init__ and the
way to pass arguments to custom template loaders isn't specified. I'm
considering it a private API.
Preston Timmons
Aymeric Augustin
David Robles
Ola Sitarska
Jon Dufresne
Berker Peksag
Baptiste Mispelon