Email template: mktoText inside a mktoBoolean declaration not working

Highlighted

Email template: mktoText inside a mktoBoolean declaration not working

Hello, I've created a template with many different modules and variables which all work great, with one exception: I have a mktoText class td inside an element for which I've added visibility control using the mktoBoolean declaration, and it seems I can only use one of the two, but not a combo.

Here is my mkto variable in the email header:

<meta class="mktoBoolean" id="top-intro-show" mktoName="Show top intro" default="true" true_value="-->" false_value="" true_value_name="YES" false_value_name="NO" mktoModuleScope="true">

And here is what the html looks like:

<!-- intro ${top-intro-show}
<table width="100%" border="0" cellpadding="0" cellspacing="0" style="font-family: Arial, Helvetica, sans-serif; font-size: 16px; line-height: 22px; table-layout: fixed;">
<tbody>
<tr>
<td class="u-center-mob" style="color: #525f7f;"><div class="mktoText" id="top-intro-text" mktoname="Intro text">Intro text goes here. Can he hidden if not used</div></td>
</tr>
</tbody>
</table>
<!-- / intro -->

I've used this boolean trick to turn many other elements on and off, and it works perfectly in combination with other variables, like a mktoString defined in the header. With the above, if I don't use the boolean variable and use <!-- intro --> instead in the html, the text element shows up in MKTO. If I use the boolean varible however, the slider is there and works as expected, but then the text element doesn't show. 

Does anyone have an idea as to why, and what I need to do in order to combine these two? It has to be a mktoText declaration, it cannot be string.

7 REPLIES 7
Highlighted

Re: Email template: mktoText inside a mktoBoolean declaration not working

Hi Elin Pedersen‌,

This might work in email editor v1, but not sure it will in email editor v2. 

I would rather use different modules in email templates v2 than this kind of hack. One module with the intro and another without the intro. It will also have the positive advantage of generating a slimmer code, without unnecessary comments when the intro is not used.

-Greg

Highlighted

Re: Email template: mktoText inside a mktoBoolean declaration not working

Thanks, Grégoire. Yes, this is the workaround I ended up applying as well. It works, just find it odd that it works perfectly with mktoString, mktoImage etc - just not with mktoText. Anyway, thanks for your reply!

Highlighted
Level 10 - Community Moderator

Re: Email template: mktoText inside a mktoBoolean declaration not working

You haven't shown the resulting HTML (the final source HTML as received by a mail client) from the non-working case.

Just the general idea of "doesn't show" isn't enough to go on. It all comes down to the HTML, there's no other magic.

If posting code, always use the Advanced Editor's syntax highlighter.

Highlighted

Re: Email template: mktoText inside a mktoBoolean declaration not working

Hi Sanford, thanks for your reply. Sorry I didn't include the full code. I haven't tested the final html of this particular template yet, since the problem seems to be in the MTKO editor, given this method works well with other variables. I have however tested this extensively on several responsive email templates where I use boolean toogles to control what elements to show or hide, and it works perfectly together with image and string variables. I've done lots of testing on Litmus where I have exported final code and have found no issues so far. Until now when I wanted to combine the boolean hack with mktoText. Anyway, I'll keep in mind your tip about the syntax highlighter.

Highlighted
Level 6

Re: Email template: mktoText inside a mktoBoolean declaration not working

Hey Elin,

That's a clever way to hide things using the Boolean toggles. I haven't had success doing this when incorporating "nested" editable areas (forms/snippets/text) inside an element that is commented out in the default state. I usually stay away from the mktoImg class (and prefer mktoText) so I haven't tested that piece before (thanks for the confirmation that it works). 

Im not 100% but my conclusion for this is that when the page loads, the section is commented out which means it is 'hidden from the computer/render' so the part of the Marketo script that recognizes this as an "editable" area in the template [pre-render] doesn't recognize it and so it doesn't render it as an editable area (i.e. add the GUI handles for the Elements and Variables panels). Then, once you turn the section on, the comments are removed and the section becomes live. Because there is only one "pass" thru the rendering process, all variables and editable areas seem to either be included-or-not in the render, so you end up seeing your new module but don't get any controls for it. In order for something like this to work, the script that's translating the editable areas would need to run a second time. 

As a rule of thumb, I've adopted the practice that if Im going to use the comments to show/hide content instead of using CSS -- display:none (or something similar) -- then anything inside that element cannot contain variables or Marketo editable areas (text, forms, snippets).

Highlighted

Re: Email template: mktoText inside a mktoBoolean declaration not working

Hi Dave, thanks for your reply. I usually use display:none for my booleans for landing pages, but since email is a different beast I went with this "comment-out-approach" instead. I second your practice that such elements shouldn't contain variables like text, since it clearly doesn't work, but since it works for strings and images, I'm thinking why not. It's very convenient to have this flexibility in an email template, and as long as the final html passes the test, then I feel safe about using this method. Thanks again for your input, much appreciated!

Highlighted
Level 10 - Community Moderator

Re: Email template: mktoText inside a mktoBoolean declaration not working

Well, keep in mind you're creating invalid HTML this way. It's only a coincidence that mail clients (and browsers) are forgiving. They don't have to be.

Note if you use a Velocity token instead of the mktoBoolean (obviously shifting the management to another part of the UI) that wouldn't disrupt the Editor (since it won't be rendered until Preview or Send).