I am trying to:
I made a WYSIWYG field and when I type " into the default value box, the code actually renders on the screen. It does not behave like another field -- single line -- which escapes the character entity correctly.
Link to a page where the issue can be seen:
I expected to see:
"Lorem Ipsum"
Instead, I got:
"Lorem Ipsum"
Beda has been helping me through social media channels. Please assign the ticket to him.
Sorry, this took so long, but I do not want to bother you with the why (due to the request to assign this to me, the supporter ignored the hint I left and assigned it to me - with a hefty time difference of half the world, here we are.)
1. I cannot replicate it.
I tested adding default values with apostrophes to the WYSIWYG Field and that shows fine everywhere on the backend.
2. However today looking closer, I see you mean a Toolset Form, where the WYSIWYG is used.
There, I can confirm there is over-escaping (not encoding, but over-escaping). I am not sure why on your end it manifests as encoded, however, it should be the same core issue, which our technical debug will show.
Example:
becomes
(In my tests)
I reported the problem and will update you here with news.
I see those marks (/) when I try to include HTML in placeholders for instance which isn't supported. hidden link
This indicates you may see them in new lines.
--Sam
I ran another round of tests.
If I go to Toolset-->Custom Fields and type in """ it doesn't render the character entity in a WYSIWIG cred field, it prints the code """ to the screen like you see in my screenshot.
If I manually type the " mark, I see the over-escaping like you do.
--Sam
I ran another round of tests.
If I go to Toolset-->Custom Fields and type in
it doesn't render the character entity in a WYSIWIG cred field, it prints the code
to the screen like you see in my screenshot.
If I manually type the " mark, I see the over-escaping like you do.
--Sam
If I use " then I see the properly written " quote, not the un-decoded HTML entity.
Both in the visual and text mode of the WYSIWYG both on Post Forms and Post edit screens.
I can, however, produce the over-escaping, and we escalated this.
Can you send me a duplicate of the site (without any third party plugins or theme, if possible) so I can check this exception?
you are misunderstanding what I'm seeing. If I type in the character entity -- the code --
Toolset does not render the "
I think I got now what you mean - if you use """ you will see " (if you first load the text mode of the WYSIWYG, not in the visual mode, where it converts)
This is the exact same in a Toolset Form, for me.
1. If you save " in the Types field settings, you see over-escaped " in a Form's Visual AND Text Mode, but correct in a post edit screen
2. If you save "& quot;" then you will see the encoded value in post edit screen backend (text mode) only the first time loaded and after, the " (correctly parsed). In a Toolset form, that is the same, in Text mode, you see the code, in Visual the quote, and also this happens only the first time you load the form in text mode, not if you switch afterwards.
I added this note to the internal ticket.
This will be fixed in the upcoming Types 3.3 release which is due within next week (not a promise, it's an estimation)
I'll update you when it's released.
Types 3.3 is now released and will fix this problem.
Thank you for your continued patience, and if you stumble over any issue please do not hesitate to open a new ticket.
