[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: |
|
||||||||||||||||
| 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 |
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 ä > 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 ] |
|
|
| 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. |
| Comment by Tobias Mattsson [ 29/Nov/10 ] |
|
Reviewed. |