Menu icon Foundation

Developer | Melbourne, Australia

My Posts


My Comments

Glenn McComb commented on Bryan Zmijewski's post over 3 years

Cool thanks for your reply Rafi, that's super helpful. 
I had a crack with the raw helper and managed to get this one to work (note the 4 curly braces):
{{{{raw}}}}Hi {{lead.First Name:default=Sir/Madam}}{{{{/raw}}}}
I couldn't get the <raw> tag to work but the above option is a big improvement on using HTML entities which make no sense and are tricky to work with.
Regarding adding attributes to the <container> and <row> elements, I had already tried that and you're right, some of the attributes make their way through, but not the IDs unfortunately (which Marketo needs). 

Glenn McComb commented on Bryan Zmijewski's post over 3 years

I build a lot of emails for Marketo and was struggling to get attributes on to elements to handle things much like what Mailchimp does. I was investigating customising the gulp-inline-css options to preserve an element's attributes and hit a brick wall, then I stumbled on this thread and realised the new updated solved my issues. I had some issues updating to the new version and ended up creating a new project and migrating my HTML partials and custom Sass to that project.
So, some notes on how I use attributes on HTML elements to build Marketo emails. Here's an example of some markup to create Modules and Containers in Marketo's new Email Editor 2.0:
<table class="mktoContainer" id="container-name">
<tbody>
<tr class="mktoModule" mktoname="Module Name" id="modulename">
<td>
<!-- STUFF GOES HERE -->
</td>
</tr>
</tbody>
</table>
I would really like to be able to do things like this:
<container class="mktoContainer" id="container-test">
<row class="mktoModule" mktoname="Article Block" id="article-block">
<!-- STUFF GOES HERE -->
</row>
</container>
... But it looks like the <container> and <row> inky elements aren't accepting custom attributes. 
On a vaguely similar note, I had a conflict with the panini / handlebars {{> includes}} syntax because Marketo's Tokens are like: {{lead.First Name:default=Sir/Madam}}. This was causing issues but I was able to get around it by using the HTML entity for curly braces: &#123;&#123;lead.First Name:default=Sir/Madam&#125;&#125.
In my previous build process (using Inky v1 and grunt) I had written some JavaScript to handle bulletproof buttons, but unfortunately Marketo's link tracking wasn't working because it didn't recognise the href="" in the <v:rect> element. It's a juggling act at times.
Really stoked to see that Zurb are committed to making Foundation For Emails work for developers.

Glenn McComb commented on Glenn McComb's post over 3 years

Ok, so I hate to be that guy but I actually just figured out how to handle this. I'm able to get the tokens coming through by replacing the curly braces with their respective HTML entities:
&#123;&#123;lead.First Name:default=Sir/Madam&#125;&#125;
Boom!
Hopefully if anyone else ever comes across this problem this thread serves as a handy reference. I'm not upset if this thread needs to be deleted.

Glenn McComb commented on Glenn McComb's post over 3 years

Just to further clarify: The unsubscribe and firstname tokens aren't breaking the build process but they are being stripped out of the resulting markup.

Posts Followed


Following

    No Content

Followers

My Posts

My Comments

You commented on Bryan Zmijewski's post over 3 years

Cool thanks for your reply Rafi, that's super helpful. 
I had a crack with the raw helper and managed to get this one to work (note the 4 curly braces):
{{{{raw}}}}Hi {{lead.First Name:default=Sir/Madam}}{{{{/raw}}}}
I couldn't get the <raw> tag to work but the above option is a big improvement on using HTML entities which make no sense and are tricky to work with.
Regarding adding attributes to the <container> and <row> elements, I had already tried that and you're right, some of the attributes make their way through, but not the IDs unfortunately (which Marketo needs). 

You commented on Bryan Zmijewski's post over 3 years

I build a lot of emails for Marketo and was struggling to get attributes on to elements to handle things much like what Mailchimp does. I was investigating customising the gulp-inline-css options to preserve an element's attributes and hit a brick wall, then I stumbled on this thread and realised the new updated solved my issues. I had some issues updating to the new version and ended up creating a new project and migrating my HTML partials and custom Sass to that project.
So, some notes on how I use attributes on HTML elements to build Marketo emails. Here's an example of some markup to create Modules and Containers in Marketo's new Email Editor 2.0:
<table class="mktoContainer" id="container-name">
<tbody>
<tr class="mktoModule" mktoname="Module Name" id="modulename">
<td>
<!-- STUFF GOES HERE -->
</td>
</tr>
</tbody>
</table>
I would really like to be able to do things like this:
<container class="mktoContainer" id="container-test">
<row class="mktoModule" mktoname="Article Block" id="article-block">
<!-- STUFF GOES HERE -->
</row>
</container>
... But it looks like the <container> and <row> inky elements aren't accepting custom attributes. 
On a vaguely similar note, I had a conflict with the panini / handlebars {{> includes}} syntax because Marketo's Tokens are like: {{lead.First Name:default=Sir/Madam}}. This was causing issues but I was able to get around it by using the HTML entity for curly braces: &#123;&#123;lead.First Name:default=Sir/Madam&#125;&#125.
In my previous build process (using Inky v1 and grunt) I had written some JavaScript to handle bulletproof buttons, but unfortunately Marketo's link tracking wasn't working because it didn't recognise the href="" in the <v:rect> element. It's a juggling act at times.
Really stoked to see that Zurb are committed to making Foundation For Emails work for developers.

You commented on Glenn McComb's post over 3 years

Ok, so I hate to be that guy but I actually just figured out how to handle this. I'm able to get the tokens coming through by replacing the curly braces with their respective HTML entities:
&#123;&#123;lead.First Name:default=Sir/Madam&#125;&#125;
Boom!
Hopefully if anyone else ever comes across this problem this thread serves as a handy reference. I'm not upset if this thread needs to be deleted.

You commented on Glenn McComb's post over 3 years

Just to further clarify: The unsubscribe and firstname tokens aren't breaking the build process but they are being stripped out of the resulting markup.

Posts Followed

Following

  • No Content

Followers

  • No Content