Are tokens not supported within "Headers, Footers, and Automated Messages"?

[mdlueck]

Greetings,

Our client's website  recently has the new member join process working as it should all the way through without getting stuck. As result, new member welcome emails are suddenly flowing out for the first time ever.

We have a Member Welcome Automated Message which includes token:

Code: [Select]

Dear {contact.first_name},
And that is exactly verbatim what gets emailed out.

I noticed upon going into the editor mode no click control to insert tokens, like I have observed elsewhere within CiviMAIL.

Are tokens not supported in Automated Messages and that is the reason I see the bare token? It is puzzling at the moment.

I am thankful,

[mdlueck]

Greetings,

aaaaaaahhh, tap tap... is this thing actually on? I would not think my question of "are tokens supported within CiviMail Automated Messages" would be that difficult to get a simple yes/no response. Could someone help me out on this small detail?

I am thankful,

[EranSch]

Not that I'm the end all in terms of Civi's features but I can confirm that the tokens go out unprocessed in the Membership Signup Receipt email, which sounds like what you're experiencing.

That said, it looks like this is only the case if you're editing the text from the actual Contribution page settings which prepends a big table of of membership and payment information. It looks like you can edit that table portion (which is composed of almost exclusively tokens) from the menu below:

• Mailings > Message Templates
• Click the 'System Workflow Messages' tab
• Memberships - Receipt (on-line) seems to be the template I'm searching for

I'm not sure if that's the solution for you but I think it might be for me.

Good luck!

[EranSch]

Yeah, I just tested this and it worked perfectly for personalizing the Membership receipt.

It appears that {$receipt_text} is the text from the contribution page config.

[mdlueck]

It appears that {$receipt_text} is the text from the contribution page config.

So you are saying I should simply swap out {$receipt_text} for the {contact.first_name} and we will end up with what we are expecting?

I am thankful,

[EranSch]

More just that you can customize that template to your heart's content. I left receipt_text in just so the email could still be semi-customized based on the usage.

I just put {contact.first_name}, above the receipt text stuff.

[mdlueck]

Oh, I see what screen you are talking about... this one:

• Mailings > Message Templates
• Click the 'System Workflow Messages' tab
• Memberships - Receipt (on-line) seems to be the template I'm searching for

And seems the same UI may be found at menu path: Administer \ CiviMail \ Message Templates which I was comparing to in my OP.

So if I build such a message, how do I get that sent by the Contribution Page \ Receipt capability? I hear what you wrote about the receipts being driving off of a more capable subsystem... still if I queue up a message in the more capable subsystem, how do I invoke that message from the Contribution Page?

I am thankful,

[EranSch]

From what I've seen so far, you just need to find the existing system workflow message that's sent for contributions and then customize it to your heart's content.

Hopefully that helps (I'm not entirely sure if I'm pointing you in the right direction)

Good luck!

[mdlueck]

Oh.... I believe I understand what you are suggesting...

Let me try to explain back what I believe you are suggesting in terms of another former product I have skills with: Borland Paradox desktop database application.

For some core functionality, Borland actually developed Paradox forms rather than implement the functionality in the lower C/C++ code. They delivered said forms (Paradox's tokenize / compile term). So if one really wanted to change something in those areas of the Paradox program, provided a de-deliver tool, one could make changes, then re-deliver said updated tool component. For example, their text file (.csv) import capability is actually a Paradox for Windows application.

So, in CiviCRM terms/lingo, you are suggesting that I locate the correct file(s) which expose minimal CiviMail capabilities through into the New CiviMember process and directly hack them as the underlying CiviMail which is going to execute the template has understanding of those tokens, just that tokens were not exposed into the port-hole view into CiviMail from the CiviMember join editor interface?

Did I now understand what you are suggesting?

I am thankful,