We’re exporting html for emails from a 3rd party (Stripo, highly recommended for designing emails). When we paste the code we generate their into the code editor for an email template, it is substantially changed in the process and our emails arrive ugly in some ways. for example:
Stripo html has things like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:o="urn:schemas-microsoft-com:office:office" style="width:100%;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%;padding:0;Margin:0">
<head>
<meta content="width=device-width, initial-scale=1" name="viewport">
<meta charset="UTF-8">
<meta name="x-apple-disable-message-reformatting">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta content="telephone=no" name="format-detection">
<title>nologo InPerson class booked to student</title><!--[if (mso 16)]>
<style type="text/css">
whereas the code editor in Backendless email template only has
<!-- [if (mso 16)]>
<style type="text/css">
In this example, it means emails received on mobile phones are tiny ugly shrunken versions of emails received in a desktop client (rather than the beautiful optimal design for mobiles).
Can anyone shed more insight into this? What is stripped out by Backendless email templates, and is there some way to work with it?
Is it a finished email template? Because if I paste it into a clear *.html file it looks empty.
Could you provide an email with some content?
As for text replacement, it comes from the editor library. It cleans all code that could cause an XSS, but if you provide some styled email we will take a look at what we can do with it.
Sure, here’s a styled email (html export from the design app Stripo, I’m not able to attach it to this comment because of file restrictions you have in the support forum).
When I compared what the Backendless editor saved vs. the original html file, there were lots of differences and things missing.
Yes, the email looks fine on desktop… but when you open it on a mobile phone (which 70% of our users do), you’ll see that it’s the desktop version shrunken down to fit (hardly readable). The original template has things to increase the font size and make the email look great on mobile… but the Backendless editor strips these things out
We have created an internal ticket to make our editor more flexible, but in order not to block your work, I can suggest the following workaround:
Go to the Files section, find the email_templates folder;
Find your email template file, click rename icon (hover over the name cell), and add a file extension .txt to it to make the file editable;
The Edit icon will appear in the Actions cell. Open file in the editor and there you will see the first line - it’s an email subject, then an empty row, and then the email body goes. Replace email body with yours and save the file;
Rename the file back (remove .txt).
You can safely open this template in the Emails section, but keep in mind that if you click Save Template there, it will overwrite and strip the body again.
Hi @stanislaw.grin thanks for this work around technique, will try it… but it does mean things will be much more awkward to work with when we want to replace text with variables… can you tell me if the file will be overwritten only if we open the “code” editor in Backendless and save? Or simply opening the template in the Emails section and clicking “Save” will strip out the formatting again? Thanks again
Code editor will not strip anything you write there. Email Templates section will strip content if you click Save button, no matter if you modify it there or not.
I understand that this workaround is much more awkward, but I can’t suggest another workaround for now. We definitely will improve this section (possibly changing the editor component, since this one can’t be configured to not strip such content).
Regarding variables in the template, you can put them in the code editor like {varName} for custom variables or {Users.firstName} for dynamic variables from the Users table.
Sounds like it will be quite some time before you might change the editor… can you tell me which particular editor is used in backendless email templates? Is it TinyMCE? I might then study the documentation and see what is and isn’t “allowed”
OK, thanks — from what I can see on their docs, there might be some settings you guys could tweak to make the editor more flexible… any chance this issue is high on your priority list? We’ll try to work with the “filesystem .txt hack” workaround for now
Also, the “paste html directly into template file in file system” trick doesn’t seem to work, mobile email is still ugly & non-responsive … somehow the sending process still seems to strip out things in the html. Not sure how that’s possible?
No, blurring not needed. Ooh, that looks nice (we can fix the avatar thing)! Is this with the Backendless editor tweaks or using the “paste html directly into template in file system” trick?
we have found a solution to this issue. I’ve already implemented it, and in a couple of weeks, it should be released. We will notify you here once it is released.
@stanislaw.grin we have run into a nasty problem with the “edit template as txt” hack to get our html into a Backendless email template: it involves character per line limits for MIME and emails (990 characters max, see here.
When sending, lines are brutally wrapped like so:
blah blah... ... blah bla=
h blah blah
That is to say that a “=” is inserted at the line end and words are broken randomly. For example, lines where we have a url for an image can get broken such that the URL gets changed from https://directory/something.com to https://directory/**=**something.com — which of course doesn’t resolve and the image doesn’t get pulled.
I notice in the Backendless template editor, code is wrapped nicely (not in the middle of a word, it doesn’t break words). But pasting in our raw html into the template file causes many lines to be longer than 990 characters… when the thing gets sent out as an email, wrapping is done brutally, just cutting words in half and adding a “=”.
Do you have a recommendation for how we might fix this? Going through the txt manually and adding line breaks by hand would be quite tedious…
