Merge tags broken?

[StynV]

Bug report

I think the merge tags are broken?

We've been using the Email Designer for months now to send form submissions to our employees.
These mails get the data in a /mailing backend call.

We insert the fields as requested:

USER: { firstname: body.firstname, lastname: body.lastname, formEmail: body.email, phoneNumber: body.phoneNumber, textArea: body.textArea, textField1: body.textField1, textField2: body.textField2, number: body.number, formId: body.formId, title: body.title },

which shows up in the Email Designer & then we pick the required values.
This has worked very good for months, since today we've been getting this in mails:

form email: first name: {{ USER.firstname }} last name: {{ USER.lastname }} form id: {{= USER.formId }} number: {{= USER.number }} phone number: {{= USER.phoneNumber }} text area: {{= USER.textArea }} text field 1: {{= USER.textField1 }} text field 2: {{= USER.textField2 }} title: {{= USER.title }}

The brackets are suddenly not being replaced by the values anymore?

[github-actions]

Thank you!! This is your first issue on this repo

[creazy231]

Hey @StynV, have you updated anything on your system? Like Strapi Version or anything else?
Because, since there was no official release of this plugin since months, it shouldn't be a problem on it's side.

[StynV]

@creazy231 that's the weird thing, we have and noticed the bug after.
Then i switched to an older branch, where the problem didn't happen, but switch to master, back to old branch & now old branch does it as well.

I even have hardcoded text not appearing in the mail. I started a new database file & stil had the issue.
Weird thing is also we have 2 mentions of firstName. First one gets replaced but second does not.

I really don't know what's going wrong all of a sudden. We do everything according to the documentation.

[creazy231]

@StynV I guess you also ran npm / yarn install, npm / yarn run build and restarted the process after switching the branches? What is happening, if checkout the old working branch locally and run your code with development settings?

For debugging emails I can recommend https://mailtrap.io/

[StynV]

@creazy231 I did yes

Is there any way I can contact you to setup a call? I tried the form on your site which doesn't work 😅
This is quite urgent for our customers. You can contact me on [email protected]

[creazy231]

good to know that form doesn't work anymore :D
currently really busy with work but will contact you. In the meantime please try to reproduce the problem locally. Maybe you can also get us a repository to reproduce the error on our side.

[PandaGerrie]

Hi @creazy231 ,

I'm chipping in with a few technical details / extra observations:

1. First of all: Strapi was running on v4.10.1 before the bug. After updating to v4.13.7 the problems started. Our staging is still on the old version and there everything works fine. Can we check somewhere if the plugin is tested with the latest Strapi version, released on 9/6/23.

2. Another thing we saw also seemed worth mentioning:
   Like @StynV stated earlier our fields for Name and Last Name still work. But I noticed that they only work if they are used before any of the other merge tags. It seems like the whole mapping stops working, once a field that cant be found is used. Can you confirm this is normal behavior.

3. Values that are not coming trough correctly are sometimes displayed as {{= value}} and other times as {{value}}. Why is the '=' there?

See the example attached:
First image: Name and Last name values are coming trough

Second image: They aren't coming trough and are showing just like the others

Also: the first field that isn't working is always shown as blank, from then on they display as their mergetags (like {{= USER.textArea }} )

Our client is getting really nervous at this point, so it would be nice if someone could take a look at this issue. If there is anything we can provide to speed up the process, let me know.

Thanks in advance!

[PandaGerrie]

Anyone else who can help here?
Again: It works on earlier versions of Strapi, but we need the newer version for other parts of the project.

[ZanKorosak]

Noticed this issue on our project as well, it started appearing about a month ago. I tested it locally and found out that only variables used as {{VAR}} are working for us.

Previously, we were using the same {{=VAR }} structure for all variables. After the issue started appearing, some of the variables disappeared when sending an email, some of them were sent without resolving. This was tested on Strapi versions 4.12.5, 4.13.2 and 4.13.7. I tested nested and normal variables. Example:

USER: {firstname: currUser.username},
CREATEDBY: user.username,
PROJECTID: body.projectId

Email-designer template:

Received email:

I also noticed that some of the content after a variable with {{=VAR}} structure disappearing. Example posted above with variables having a '=' before:

[StynV]

@ZanKorosak so what you're saying is that the way of defining Merge tags in plugins.js must be changed?
mergeTags: [ { name: "Form Email", value: "{{= USER.formEmail }}", sample: "[email protected]", }, ]
must become

mergeTags: [ { name: "Form Email", value: "{{ USER.formEmail }}", sample: "[email protected]", }, ]

?

[StynV]

This seems to have fixed the issue

@creazy231 is it possible to give some kind of notion in the README.MD ?
This is quite a breaking change which you don't notice when updating strapi considering everything is setup to the old documentation.

[BayBreezy]

It is a breaking change. I Saw that the README was updated after @creazy231 made some changes to the repo some time ago.
Now you have to use the {{ VAR_HERE }} syntax for variables to be recognized. Its not that the update in Strapi version caused it, this plugin got an update that broke the old syntax.

Check the mustache docs here to see how to use vars, loops etc in the email template from now on: https://mustache.github.io/mustache.5.html
The repo can be found here: https://github.com/janl/mustache.js#usage

[creazy231]

flagged the PR as a breaking change ( #128 ) but for some reason it wasn't merged into a major release