When altering from e.g. an IntegerField to a ForeignKey, Django didn't
add a constraint.
Backport of f4f0060feaee6bbd76a0d575487682bc541111e4 from master
Regression introduced in 3d4a826174b7a411a03be39725e60c940944a7fe
Thanks IRC user ris for the report, Loïc Bistuer, Anssi Kääriäinen and
Andriy Sokolovskiy for the discussion and Tim Graham for the review.
This regression was caused by 818e59a3f0. The patch is a partial
backport of the new FileResponse class available in later Django
versions.
Thanks Raphaël Hertzog for the report, and Tim Graham and Collin
Anderson for the reviews.
Thanks Florian Apolloner for the report and Claude Paroz and Tim Graham for the review and help on the patch.
Backport of 737d24923ac69bb8b89af1bb2f3f4c4c744349e8 from master.
Thanks Peter Schmidt for the report and the initial patch.
Thanks to Oktay Sancak for writing the original failing test and
Alvin Savoy for supporting contributing back to the community.
Backport of d7bc37d61 from master.
Refactored bump_prefix() to avoid infinite loop and allow more than
than 5 subquires by extending the alphabet to use multi-letters.
Backport of 41fc1c0b5eac156e200a10233c7c9210a1c0fed8 from master
This reverts commit 1702bc52cc20ed0729893177fc8f4391b4b3183c.
This doesn't work on stable/1.7.x because #23844 wasn't backported and we're
not willing to do so because it's a large change.
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.
Backport of 6d52f6f from master.
mark_safe and mark_for_escaping should have been kept similar.
On Python 2 this change has no effect. On Python 3 it fixes the use case
shown in the regression test for mark_for_escaping, which used to raise
a TypeError. The regression test for mark_safe is just for completeness.
Backport of 5c5eb5fe from master.
