Email template plain text editor read issue

[pepies]

Summary
When creating new email template under System-Email-templates.
New template of type plain text is created succssefully, also data in databse are exactly how they suppose to be and how user have written them to field Template data -> content.
But after reopening this template data is loaded sth stripped newlines and stripped special characters like ľščťžýáíéúä...

Steps to reproduce

• create new template with rich data, ex:

ešešešešeše
rčrčrčrrčrčrčr

• open it

Actual Result

eeeeeeerrrrrrrr

Expected Result
same as inserted (eg. in oro_email_template db table)

Details about your environment

• OroPlatform version: 4.2.1
• PHP version: 7.4.14
• Database MySQL 5.7.12
• [Optional] Client browser and its version: tested at mozzila and chrome, both bad (not only for me)

[anyt]

Hi @pepies,
To use special characters with MySQL, you have to set up the charset to utf8mb4.

Also, pay attention that the Mysql 5.7 officially is not supported for the OroPlatform 4.2 and we recommend upgrading to 8.0.

[pepies]

@anyt Hi, thank you for your response. I appreciate it.
But I must mention that as I said in issue description, database is not the problem, data are persisted right also fetched right.
We have tested your suggestion, but it won't helped. The one thing that hepled was disabling wysiwyg editor.
It works ok now, but we need wysiwg for Html templates.

[pepies]

example:

Behaviour: At first it is ok with wysiwyg, than editor buttons are hidden, text is still ok, than some loading appears and text box is hidden completly, than text box is shown with wrong formating (i dont know if immediatly or there is middle step)

[anyt]

Make sure it's not the browser or browser extension issue, then.

I cannot reproduce it locally and still think it is related to the database encoding, as your STR is similar to what I saw with the default encoding.

The screenshot is made after form save and full page reload:

Details about my environment

• OroPlatform version: 4.2.1
• PHP version: 7.4.14
• Database MySQL 8.

[pepies]

Thank you for your effort. I feel like you have not tested it with described type.
It should be plaintext. (While wiswyg is turned on-seems on at sceen).
Than save template and open(for edit) again.

I am sure it is not browser thing. Also my 3 colleagues tested it today and it behaves the same.

If it would be database issue than data should be broken at response/teplate already, but they are ok. I guess there is some js reformatting that I was not able to track.

[anyt]

🤦 My miss, sorry for wasting your time by being inattentive. Now I can reproduce it.

It's definitely a bug, but it's minor, as you still can switch back to the WYSIWYG editor or disable the WYSIWYG completely for the whole application in the system configuration.

Thank you for your contribution and patience.

Internal ticket id BAP-20469

[pepies]

Just for someone having same issue.
I have hacked it with calling this jQuery
this.$('textarea[name*="content"]:first').val(this.$('textarea[name*="content"]:first').prop("defaultValue"));
sometime after all this morphing.
The core issue seem to be in deserialization of html_encoded content: this is how translation is presented