Developer forum

Looks like my @If condition messed up the logic. removing it, gave me the result i wanted, but i tried something else after i got it working..

This code:

<!--@If(EmailMarketing:Email.PreHeader.Clean='')-->Her indsættes 'Preheader' teksten som sættes op i Email Marketing modulet<!--@EndIf-->
<!--@EmailMarketing:Email.PreHeader.Clean-->

I expected this snippet to render "Her indsættes 'Preheader' teksten som sættes op i Email Marketing modulet" when building the email page, and the actual Preheader text when i send out my campaign.

Sadly the result of this snippet is this when i recieved my e-mail:

Her indsættes 'Preheader' teksten som sættes op i Email Marketing modulet Preheader text

Is there something special regarding @If statements in Email Marketing that i need to know about?

// Martin

The email marketing placeholders are not template tags as we know them. They are simple text placeholders and cannot be used in @If expressions.

Check out Working with placeholders for details.

Best regards,
Mikkel

Hi Mikkel,

That seems weird. If the tags are in the list of available Page templates, then they should work with the template logic that work for all the other tags.

I'm not using the {{tag}} variant of the tag, i'm using the <!--@--> format, and therefor i have no reason to think that the @If's wouldn't work.

// Martin

I know that the Handlebar syntax is special for Email Marketing, but why is the normal syntax way (<!--@tag-->) implemented in a way where it looks like a normal template tag, but it shares none of the same logic?

IMHO you're creating an inconsistent experience for developers.

Can you share your reasons for having <!--@tags--> that don't work like all the other tags?

// Martin

Hi Martin,

The reason the template tag syntax was implemented originally was because we could use the existing Rendering APIs to placeholders substitution, and that would allow for proof-of-concepts to be developed more quickly.

Internally, after the release of the beta version of the module, we realized -- just as you point out -- that the shared notation could be confusing and, therefore, we implemented a new way of handling placeholders. Since the module had already been released and the original template notation was already being used by multiple sites, we could not just remove support for it without warning.

It was decided that tag notation placeholders would be removed from E-mail Marketing from Dynamicweb 8.5. I have said this on multiple occations, including Tech Conference 2014. Unfortunately, due to factors both internal and external, the support was not removed from 8.5, though we are going to remove it from Dynamicweb 8.6.

This means that only the handlebar notation style will be available for placeholders. Using, for example, conditions on placeholder values from a given e-mail is still not possible as the e-mail content, that is the template, is usually only rendered once and then only placeholders are replaced for each recipient. We are exploring ways of opening up this avenue of more dynamic templates based on e-mail/recipient values, but at the moment we do not have a solution to share.

- Jeppe

Hi Jeppe,

Thanks

I understand that you need to seperate Page Template logic from Email Marketing logic, but i'm not 100% certain that we agree on where to draw the line.

But deciding what logic to put where is a tricky task, but i'd argue that we need as much of the logic in working template tags as possible. Since we want to make the template as intelligent as possible to avoid user errors.

// Martin

Believe me, we get that.

The issue is the trade-off between functionality and performance. If we were to enable the full-blown template engine, we would have to render the complete template for each recipient and that would be very costly from a server resources viewpoint. In fact, during internal tests we were able to bring a server to a crawl making it in essence useless. This process, of course, can be throttled but that brought the throughput way down.

Doing a simple placeholder substitution is much less demanding and it was decided that this would be the primary way of dealing with e-mail content. It is also the recommended way when sending large numbers of e-mails.

Since then, we've introduced an option to render content for each recipient -- basically what I talked about in the first paragraph. For now, we have limited the use case of this to directed communication, like abandoned shopping carts.

Still, I think that simple placeholder substitution will be the primary way E-mail Marketing handles content. But like I said in my first post, we are discussing ways to improve the functionality, maybe some combination of recipient-specific content and the full Rendering API. We need to make something that makes sense in simple and advanced scenarios. Currently though, we do not have anything concrete to share.

I will add a +1 from you to the task in our backlog. Consider this a formal Feature Request :)

Hi Jeppe,

Once my initial frustration ran out, i can ofcourse see your points, and we can't always have the best of bother worlds (template freedom and performance) - i really do like and want them both :-)

After 8.6 there will be a more clear sepration between what templates work where.

I do however think that one tag is categorized wrongly:

EmailMessaging:Message.DomainUrl: This tag is used to get the absolute URL for ressources in your email, and therefore it has to work when building the page, and when sendig the newsletter. It can't output !!Placeholder!! when rendered in Page context.

Other than that, i just need to get used to placeholder tags i guess :-)

// Martin

With regard to EmailMessaging:Message.DomainUrl, from 8.4.1.0 the EmailMarketing:Email.ContentLink.Clean tag does produce a link that contains the recipientId, and then the page renderer can detect that this is a page used in an e-mail and with the recipientId, it can replace the content on the page just as it did in the e-mail. Basically, it should be the exact same content. Links, placeholders and all.

One problem is that this does not work, if the page is accessed directly from the site and not from the link in the e-mail. In this case, the recipientId is not present and the standard placeholder (!!Placeholder!!) value is used.

And before you get nervous, the recipientId requires a token in order to work :)

But that means that it's impossible to create a newsletter template (in a designs folder) that uses the EmailMessaging:Message.DomainUrl tag and that still works in both a page preview and in a newsletter?

I don't want to hardcode domains into my template, i want to use the "Domain" field in the Email Marketing module, but that's impossible now since the tag is  replaces with !!Placeholder!! in Page preview.

Se this: http://developer.dynamicweb.com/forum.aspx?ThreadID=38064

Maybe i'm just going about this the totally wrong.

Can we get Mikkel Ricky to create a best practice example of all the Email Markting Placeholder functionality :-)

// Martin

You are correct, and it is an issue that we need to solve. The biggest problem is, how do we determine the correct url if you can create multiple e-mails that use the same page and send it using different domains.

One solution would be to not allow the domain to be selected in the e-mail configuration and always use the domain of the page. This is not necessarily a good idea and not something we really want to do.

Another solution is to only allow e-mails that use that page to use the same domain, but this option has a lot of the same concerns as the above mentioned solution.

A third solution could be to allow the editor to select an e-mail on the page. Information from that e-mail could then be used to substitute certain placeholder values. In this case, the information on the page is still limited to the selected e-mail, and could potentially display incorrect information for those who navigate to the page after receiving a different e-mail to the one selected on the page. This is probably the least bad option, but still not elegant.

If we don't have a direct relationship from page to e-mail, we can't infer the domain with any real certainty, and this is the main reason that it works this way currently.

Hi Martin

We have received an escalation on these issues.

Could you please clarify what you would like us to take a look at?

Thanks for clarifying.

Nicolai

Hi Nicolai,

In short i'd like you to fix this tag: EmailMessaging:Message.DomainUrl

Here's a thorough description of the problem: http://developer.dynamicweb.com/forum/cms-standard-features/email-marketing-emailmessagingmessage-domainurl-is-messed-up.aspx

// Martin

Hi Martin

I've created TFS#15948 due in 8.5.1 that will render some data in the placeholder tags if applicable.

The following tags are now filled with data from the preview pageview if available. The domain is taken from the current host, the name and email of recipient and sender is taken from the user currently logged into the administration.

If no user is logged in, placeholder texts are shown.

EmailMessaging:Message.DomainUrl: <!--@EmailMessaging:Message.DomainUrl--> <br />

EmailMessaging:Message.Subject: <!--@EmailMessaging:Message.Subject--> <br />

EmailMessaging:Message.SenderEmail: <!--@EmailMessaging:Message.SenderEmail--> <br />

EmailMessaging:Message.SenderName: <!--@EmailMessaging:Message.SenderName--> <br />

EmailMessaging:Recipient.Name: <!--@EmailMessaging:Recipient.Name--> <br />

EmailMessaging:Recipient.Email: <!--@EmailMessaging:Recipient.Email--> <br />

BR Nicolai

Sounds about right :)

8.5.1 is out byt the end of October right?