Please fix silent failure of the template editor

[Anonymous]

In the words of Jackie Chan Adventures "bad day, bad day, bad day!"

Surely, there are many of us who work with templates simply copy/paste externally created code into the Marketo editor, and put our faith in the "approve and close" function to do a proper code inspection, report any and all issues, and then, if it's all good, close the tab/window. Well, I experienced the dreaded "silent failure" today.

Try this HTML template, for example, to create a "guided template". [ marketo-hates-raiased-mc.html · GitHub  ]

Marketo's editor will happily save and close. Re-open it for editing. Did you lose all the data after the second "Food"? I totally did

I was left with only a portion of my template. The rest was amputated. [ marketo-ate-my-work.html · GitHub  ]

We're paying good money for this database system. It shouldn't mangle the data. This error ruined a good number of pages that were updated in a long batch, manually performed.

Fix it, please, by processing everything properly at every stage of the pipeline.

[Justin_Cooperm2]

We're looking into it.

[Anonymous]

How's that "looking into it" coming along, Justin?

[Justin_Cooperm2]

We have a bug open for this. Our engineers are going to see if it's possible to support it. Note that it is not supported by several browsers (see http://www.fileformat.info/info/unicode/char/1f16a/browsertest.htm​), and we generally try not to enable things that won't work for a majority of people. I am on latest version of Chrome/Safari and it doesn't render for me.

In the meantime, avoid using character U+1F16A in your templates.

[Anonymous]

The ideal outcome is "All of UTF-8 now supported", of course.

As a stop-gap measure, at the very least, the system should not perform a silent data corruption; it must at least warn the user. I've gone through the trouble of ruling out the front-end. It's a back-end problem. Whatever receives the HTML template and saves it is not doing it properly.

Please take care to understand that I am not particularly interested in the "raised MC sign" getting supported on its own. What I am actually worried about is inadvertently using other characters in UTF-8 that also cause the same truncation / corruption. It just so happens that "raised MC sign" was the first character identified to do this.