Fixed WYSIWYG-editor doesn't parse HTML on form validation fail

[juuser]

Just noticed this with J5.0.0 and F4.4.1 (both JCE and TinyMCE have the same behavior).

When you have e.g. "Some text" in the editor, then try to save the form and the validation fails, "Some text" becomes "<p>Some text</p>". And when you try to save again with failed validation, then "<p>Some text</p>" becomes "<p>&lt;p&gt;Some text&lt;/p&gt;</p>" etc.

And when you finally save the form, textarea keeps all the unparsed tags.

All textarea settings are default, except obviously WYSIWYG-editor set to "Yes".

So it seems that something has changed regarding this lately, because at least F4.0.0. on J5.0.0. doesn't seem to have this bug.

EDIT: textarea field itself doesn't have any validations set.

 

[troester]

There was a fix in F4.4.1 to handle e.g. '<' character in the text
https://bitbucket.org/fabrikar/fabr...iff2=538efbdcdb9addad2d814e9708621d0fd1c94e41

which is working on a successful save but obviously not in case of a failed validation.

 

[juuser]

Thanks Troester,

That definitely seems to be the culprit. Removing this line solves the issue. And I cannot replicate the original issue for what this line was added for. "<" and ">" characters in the editor seem to save just fine without the Bitbucket addition.

 

[troester]

The issue is if you have < and > which was working in F3 and can be used in J! articles following
https://fabrikar.com/forums/index.p...-wysiwyg-editor-deletes-test-on-saving.54428/

But I think this is some sort of editor issue (HTML cleaning of unknown "tags") and/or a corner case.
So I'm going to undo this commit...

 

[troester]

Can you try to put before line 377

if (!$this->form->failedValidation()) $value = htmlspecialchars($value, ENT_COMPAT, 'UTF-8');

So adding the condition and moving it before the wysiwyg as @Roland is asking for.

There are still issues with details view and < character but this is an other topic (same with field elements).

 

[juuser]

Thanks! Quick test shows that this fix seems to be working great! HTML-parsing issue does not occur and also e.g. "<123>" is preserved.