sendgridsendgrid-api-v3sendgrid-templates

SendGrid Dynamic Templates always produces non-ASCII symbol instead of HTML escaping, causing Message Clipped


Question: Has anyone had any luck forcing Sendgrid Dynamic Templates to use © with a text module inside a single-column layout? It always produces the non-ASCII © for me.

Detail Gmail penalises any content that contains non-ASCII characters. When it detects this it shows the "Message clipped" message at the bottom. This is not an ideal professional look.

enter image description here

The source of this for us was the © copyright symbol. This is because Sendgrid Dynamic Templates always passes this directly with non-ascii version instead of using html-escaped ©

I tried to get around this by editing the html and forcing © but the editor simply replaced it with the bad © char each time.

Steps to reproduce:

  1. Create a single column layout with a text module inside. Add “Test copyright ©”
  2. Edit module HTML for text component. It will initially have the © Symbol in there
  3. Change to be html-escaped © and click Update
  4. Repeat step (2) to view the source and the source code will contain the unescaped copyright © symbol. This will continue to cause "Message clipped"

Solution

  • I've raised a request with SendGrid as I think this is a bug, but a note for others meanwhile is that you can work around this by:

    1. Creating a Code component inside your single-column layout,
    2. Copy any styling you want from the original Text element by viewing the source
    3. You may also need to copy any padding, line-height from the table of the original text element by viewing the source of the generated template

    This got me my outcome, but obviously isn't as easy to allow non-tech authors to maintain the content.

    Update 9 Feb 2023

    SendGrid support have confirmed the bug with all rich text editors. Copyright symbol is always replaced with unicode character instead of html escape code. Should ideally always convert known special characters to html escape codes, but at a minimum it should honour when someone overrides in the code section rather than replacing it. Bug raised, no ETA or idea of internal prioritisation. Meanwhile workaround above will get you by ... just makes it harder for non-technical authoring.