This may cause some backwards compatibility issues, but may also
resolve security issues in third party projects that fail to heed warnings
in our documentation.
Thanks Markus Holtermann for help with tests and docs.
Backport of fa350e2f303572ee8f9a8302dda45a12288d3d95 from master
This opens more possibilities, like accessing context.template.origin.
It also follows the chain of objects instead of following a shortcut.
Backport of 1bfcc95 from master
If Django is installed in a path that contains non-ASCII characters,
the tag failed with UnicodeDecodeError.
Backport of 098fa12dd390e733c7568d824eea2c346550c75a from master
The function implemented most of upath(), but skipped the check for
strings that are already unicode.
Backport of bad6280c4e3f75f3ccd27f8fd85a4043bb296128 from master
Explicitly checking for django.template.Template subclasses is
preferrable to duck-typing because both the django.template.Template and
django.template.backends.django.Template have a render() method.
Thanks spectras for the report.
Backport of 47ee7b48 from master
This reduces the length of rope RequestContext gives users to hang
themselves with.
Thanks Alex Hill for the report and Tim Graham for the review.
Backport of f2c104a from master.
This significantly improves performance on PyPy. The previous
implementation would generate a new class on every single request,
which is relatively slow.
Backport of 8099d33b6553c9ee7de779ae9d191a1bf22adbda from master
If importing or initializing a template backend fails, attempting to
access this template backend again must raise the same exception.
Backport of 44ad6915 from master
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.
Backport of 2133f31 from master.
Conflicts:
docs/topics/http/shortcuts.txt
tests/generic_views/test_base.py
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.
