Sanford Whiteman

Storing “live” HTML in {{lead.tokens}}

Blog Post created by Sanford Whiteman on Jul 31, 2019

You might not have noticed that {{lead.token}} values are HTML-encoded in Landing Pages. (Upfront note: this is A Good Thing, since it’s the secure-by-default approach.)

 

So if you have a Text Area field (same goes for String):

 

 

And you just drop that into an LP:

 

 

You’ll see the exact textual representation in the approved page — that is, in this case, you will not have a clickable link:

 

 

Of course, this is because the underlying HTML source is a “dead” text representation of the value, not a “live” <a>:

 

 

There isn’t anything wrong with this default behavior and it’s far less dangerous than rendering HTML by default.

 

But if you need to “resuscitate” such tokens — only if they’re from a trusted source — first make sure they’re placed inside easily identifiable HTML containers. In this case I’m taking a page from the Marketo Email Editor and setting the data-allowhtml attribute on a surrounding <span>:

 

 

Then add the related JS to the <head> of the LP:

 

document.addEventListener("DOMContentLoaded",function(e){
var arrayify = getSelection.call.bind([].slice);
arrayify(document.querySelectorAll("[data-allowhtml='true']"))
.forEach(function(htmlable){
htmlable.innerHTML = htmlable.textContent;
});
});

 

And now it’s a true-and-living <a>!

 

 

You might want to hide (display: none) the elements until they’re resuscitated but I leave that to you.

 

Only Built for Trusted Linx

Be careful with this workaround, though: only use it if you’re 100% sure the data and the output context can be trusted. If the value was populated via form fillout and never sanitized, it is definitely not trusted! While if it was synced over via a managed integration, it might be trusted.

Outcomes