Escaping curly brackets in mautic e-mails

Your software
My Mautic version is: v3.2.4
My PHP version is: 7.3.26
My Database type and version is: mysql

Your problem
My problem is:
I want to escape a curly brackets content on the emai to be handled by the SMTP server.
I am using elastic email as my smtp provided, their documentation says I can customize the unsubcription url by providing the following content in the email body:

{unsubscribe:http://redirect-to-your-own-unsubscribe}

I used that pattern, but when I received the message nothing is there, I think the fact that curly brackets is also replaced by Mautic, makes the body of the e-mail change before it gets to elastic mail.
is there a way to escape curly brackets? like \{ ?

These errors are showing in the log:
No Errors in the log
Steps I have tried to fix the problem:

So… who do you want to do the unsubscribe? Elastic or Mautic?

I want to include this tag in the body of the e-mail:

{unsubscribe:http://redirect-to-your-own-unsubscribe}

and I don’t want mautic processing that token like it would process tokens like:
{contactfield=firstname}
or
{webview_url}

I would like to mautic to ignore that string and pass it as is to the SMTP service, the service will be responsible to replace that token, from my initial test, the content is erased all together. I am not sure where the content is lost (if it was dropped by mautic or the smtp service) I will have to do additional tests to determine that.

here is what I am trying to achieve (see the section “Integrating the unsubscribe link”)

so, the parsing of the curly brackets may have a unexpected behavior depending on the content of the bracket and how do you build your e-mail.

Scenario

  • I am using mautic version v3.2.4 - the docker distribution and elastic Email as the SMTP server.

  • I want to create an e-mail with “variables” A.K.A. contact fields and email tokens in Mautic and merge fields in Elastic Email.

  • Both tools uses those variable with very similar syntax: single curly brackets,
    example {contactfield=firstname}. the syntax difference between the tools is that mautic uses “=” (equals) for subvalues and Elastic Email uses “:” ( colon ).

  • My Goal is to use variables from both environments and allow each tool to handle their own variable

Expected Behavior

  • The e-mail message is processed by Mautic First, he replaces the known variables with the proper values and ignores the variables it does not known. passing the string as is to Elastic Email

  • Elastic Email then process the message replacing the variables it can recognize with the proper values

Actual Behavior

All the known variables were replaced by Mautic.
the expected behavior seems to occur for the majority of the cases, the issue happens when the string between the curly Brackets contains a colon (":") - If the variable does not contain a colon the replacement works as expected for both Mautic and Elastic Email
I tested this specific Elastic Email variable {unsubscribe:http://mydomain.com} which can be found in Elastic Mail Documentation. next section describes the behavior when using this type of variable

What happens when I use Elastic Email variables containing colon:

  • When using the email builder, If I select a template and use the text slot, I am able to use the variable in plain text without a problem but not inside an HTML code, I try to used inside the href attribute and when I receive the e-mail, the link was removed, only the content that was inside <a> tag appears.

<a href="{unsubscribed:https://myurl.com}">Unsubscribe</a> will generate a plain “Unsubscribe” text

  • when using the code mode, where only the HTML code is presented, the variable inside the <a> tag works as expected

Conclusion with This Problem

A very specific markup is not working inside the text slot of the e-mail builder - It is a good idea to review / test this behavior in mautic for future updates. For me the fact that the link works on the Code Mode is good enough but I can see this being a problem for someone who is not familiar with html

it may seem a small thing, but this is actually important to track the unsubscription process that is independently managed by the Elastic Email service, I will write another topic about this because I think it is something interesting for this community

1 Like

Very good idea, I’ll add it to the idea list and will bring it up to the Email Tiger Team.
Thank you for the great description, examples and tests.

Joey

Hi,

I’m trying to implement exactly the same unsubscribe workflow you described above.

I can’t figure out though which ‘myurl.com’ should be used between the curly brackets: {unsubscribed:https://myurl.com}
→ is it my Mautic domain url? Is it my Mautic domain url for unsubscribe and if so, where can I find it?

Many thanks in advance.

Hi Pegasus,

my main purpose of this was to provide a custom landing page to keep the (un)subscription fully customize, so the url would be a custom landing page with a custom form to collect confirmation and reason for unsubscription. if you are planning this, the url would be of the landing page you are building

if you would like just to point to the default mautic unsubscription page you can use the variable {unsubscribe_url}, for example:
{unsubscribed:{unsubscribe_url}}
but I have not tested the use of brackets inside brackets to be sure it would work, let me know if it works for you.

also, if your plan is just to add the person to the “do not contact” list, there are simpler options, you can configure Elastic mail to notify Mautic for any bounce or unsubscribe event, the instructions on how to do so can be found here:

Hi Leoschuler,

Many thanks for your support, this thread, and your answer, have been extremely useful.

The {unsubscribe:{unsubscribe_url}} is enough for us and works perfectly fine.

In relation to “also, if your plan is just to add the person to the “do not contact” list, there are simpler options, you can configure Elastic mail to notify Mautic for any bounce or unsubscribe event”, we tried that option but faced a few issues including:

In any case, this thread resolved our issues for now.

Many thanks.