Thanks to Chris Beaven for the initial patch, Fredrik Lundh for the basis
of the parser methodology and Russell Keith-Magee for code reviews.
There are some BACKWARDS INCOMPATIBILITIES in rare cases - in particular, if
you were using the keywords 'and', 'or' or 'not' as variable names within
the 'if' expression, which was previously allowed in some cases.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11806 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The max_width argument now passes through FilterExpression which by side-affect
allows float values, but will be truncated.
Thanks obeattie and Eric Holscher for patches.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10352 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This was the (undocumented) behaviour prior to r10118 and now it's back
again. It's neither hard nor harmful to maintain compatibility with the
old ways.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10169 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Most of the hard work for this was done by akaihola.
There are still possibly some problems with the i18n template tags,
since they are written quite differently and a few other bug fixes have
to made before they can be fixed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10119 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Some template filters and tags understood single-quoted arguments, others
didn't. This makes everything consistent. Based on a patch from akaihola.
Fixed#7295.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10118 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is like "safe", except it operates on the individual elements of a
sequence, rather than treating the whole argument as a string.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9952 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Astute readers will notice that the patch originally called this `default`; after consideration I decided that `empty` is a very slightly better color for this particular bikeshed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9530 bcc190cf-cafb-0310-a4f2-bffc1f526a37
passed in for the connector. This was contrary to what the documentation
for autoescaping said and to what every other filter does with literal
strings as arguments.
This is backwards incompatible for the situation of the literal string
containing one of the five special HTML characters: if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo| join:"&" }}.
Previous behaviour was, as noted, a bug and contrary to what was
documented and expected.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9442 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We now raise UnicodeDecodeError for non-UTF-8 bytestrings (thanks to Daniel
Pope for diagnosing this was being swallowed by ValueError) and allow UTF-8
bytestrings as template directories.
Refs #8965.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9161 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There's no guarantee about the order in which ambiguous patterns are resolved.
The solution is "don't do that" and avoid ambiguity.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9113 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is fully backwards compatible, but it fixes a bunch of little bugs. Thanks
to SmileyChris and Ilya Semenov for some early patches in this area that were
incorporated into this change.
Fixed#2977, #4915, #6934, #7206.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8760 bcc190cf-cafb-0310-a4f2-bffc1f526a37
times. Patch from Jeremy Carbaugh.
This is backwards incompatible in the sense that previously, if you tried to
compare timezone-aware and timezone-naive values, you got an incorrect result.
Now you get an empty string. So your previously incorrect code returns a
different incorrect result.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8579 bcc190cf-cafb-0310-a4f2-bffc1f526a37
invalid characters are correctly escaped. This avoids any chance to inject raw
HTML inside <script> tags. Thanks to Mike Wiacek for the patch and Collin Grady
for the tests.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8577 bcc190cf-cafb-0310-a4f2-bffc1f526a37
the timeuntil tests to fail because the pre-recorded "now" has moved on
sufficiently far from actual "now()". Fixed the one test that was failing for
me (the other timeuntil and timesince tests already have a small buffer built
in to guard against this problem).
The problem was revealed after [8535].
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8556 bcc190cf-cafb-0310-a4f2-bffc1f526a37