Django

Code

Ticket #6948 (closed: fixed)

Opened 2 years ago

Last modified 1 year ago

Join filter string literal escaped, docs say it shouldn't

Reported by: dougvanhorn@gmail.com Assigned to: mtredinnick
Milestone: Component: Template system
Version: SVN Keywords: join filter stringliteral
Cc: Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Per the template documentation, string literal arguments are inserted into a template without being escaped, e.g.,:

{{ foo|default:"&" }}

renders:

&

and not:

&

But when I do:

{{ foo_list|join:" & " }}

I get the HTML:

1 & 2 & 3

instead of:

1 & 2 & 3

In other words, the string literal supplied to the join filter is escaped, where the docs imply otherwise, or at least aren't quite clear IMHO.

I've provided a patch that fixes the problem with the join filter that conditionally escapes the user data but leaves the string literal unescaped.

Attachments

defaultfilters.patch (1.3 kB) - added by dougvanhorn@gmail.com on 04/02/08 14:39:33.
Patch for join filter.

Change History

04/02/08 14:39:33 changed by dougvanhorn@gmail.com

  • attachment defaultfilters.patch added.

Patch for join filter.

06/14/08 07:07:42 changed by telenieko

  • needs_better_patch changed.
  • component changed from Uncategorized to Documentation.
  • needs_tests changed.
  • summary changed from Join filter arg being escaped. to Join filter string literal escaped, docs say it shouldn't.
  • needs_docs changed.
  • stage changed from Unreviewed to Accepted.

10/07/08 07:42:10 changed by mtredinnick

  • owner changed from nobody to mtredinnick.
  • status changed from new to assigned.
  • component changed from Documentation to Template system.
  • stage changed from Accepted to Design decision needed.

Argh. :-(

This is correct, but I wish it had of been filed under the right component so we might have noticed it in the lead up to 1.0. Fixing the join filter properly will be backwards incompatible in a unsafe way (if you haven't HTML-escaped the literal, it will appear as non-escaped if we change this). So we might just have to wear the inconsistency and document it.

I'll think about it.

10/07/08 20:45:35 changed by SmileyChris

Since the docs explicitly state that literals are safe data, I'd say this is a bug fix.

11/14/08 19:16:21 changed by mtredinnick

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [9442]) Fixed #6948 -- The join filter was escaping the literal value that was 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.

11/14/08 19:24:54 changed by mtredinnick

(In [9443]) [1.0.X] Fixed #6948 -- The join filter was escaping the literal value that was 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.

Backport of r9442 from trunk.


Add/Change #6948 (Join filter string literal escaped, docs say it shouldn't)




Change Properties
Action