[MGNLFORM-52] Form paragraph title and text are encoded twice Created: 19/Jul/10  Updated: 29/Nov/10  Resolved: 05/Nov/10

Status: Closed
Project: Magnolia Form Module
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: 1.2

Type: Bug Priority: Major
Reporter: Zdenek Skodik Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLSTK-664 Some form fields values are encoded t... Closed
is cloned by MGNLSTK-676 wrong encoding in search box and sear... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   
  • at STKParagraphRenderer.wrapNodeForTemplate() - STKUtil.encode()
  • and at form.ftl

As a result, if one enters characters which have an html-entity equivalent (angle brackets, ampersand, accented letters, ...), the browser displays text such as "the &auml; &gt; text" (instead of "the รค < text" in this example)



 Comments   
Comment by Magnolia International [ 19/Jul/10 ]

After a quick investigation, it looks like those fields are indeed encoded twice, but only in the context of the public-user-registration forms, or maybe some others; the "default" form paragraphs of the form module are of type freemarker and not stk, and as such do not go through the STKParagraphRenderer.wrapNodeForTemplate() code.

When using the contact form of the stk demo, for example, the double-encoding issue does not happen.

The "problem" is that the same ftl template is used in both types of paragraphs.

To avoid further confusion and problems, we should revert the current fix. One possible other solution is to change the p-u-r integration paragraphs to not be of type stk, but these being currently defined in STK, it might not help make things clearer either. Duplicating the ftl files is not desirable either. Since we need an overhaul of the stk-pur integration, we might want to take that opportunity to fix this issue in a more acceptable fashion too.

Furthermore, we need to consider that 1) HTMLEncodingContentWrapper is applied before the Freemarker ?htlml built-in 2) HTMLEncodingContentWrapper currently encodes any character into its html-entity equivalent, while Freemarker's ?html built-in only encodes <, >, " and &. I'm not sure which behavior should be favored.

ref: freemarker.core.BuiltIn.htmlBI

Comment by Magnolia International [ 19/Jul/10 ]

MGNLSTK-664 is probably fine, since the impacted paragraphs there are indeed of type stk, but we should carefully consider those as well when re-fixing this issue.

Comment by Jan Haderka [ 19/Jul/10 ]

Nice catch. I agree that we need a consistent approach and I've reverted the changes for now.
Further more the html encoding is not applied in all the templates in the form module consistently. Most of the fields do not have encoded title and description, hidden field doesn't have encoded even the value.
The reason why all the STK content is wrapped is to prevent forgetting to use the ?html builtin in the templates.

Comment by Tobias Mattsson [ 29/Nov/10 ]

Reviewed.

Generated at Mon Feb 12 05:36:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.