Should MessageTemplate.send support tplParams with Smarty disabled?
The api3 MessageTemplate.send action has supported tplParams
since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: {$paramname}
- which are different to [entity.tokens]
. It's super useful for transactional mail where you want to include extra info as a one-off.
The api has done this by assigning the given key value pairs as Smarty variables.
More recently (2020) the api action added support for disabling Smarty, since it wasn't playing nicely with message template content generated by Mosaico.
Without Smarty, tplParams
does not work.
tplParams
without Smarty.
I would like to see support for I think the concept of a message template is that it is a flexible template for emails. (Adding token support for one-off context-sensitive use-cases is very inefficient and is likely to end up with hackish situations where the data that needs to be in the email does not need to be in the database.)
I mistakenly thought that it used to work this way, and so I wrote a PR to fix what I saw as a regression, adding tests to boot. https://github.com/civicrm/civicrm-core/pull/19062 however this stalled, because it turns out it wasn't a regression, and so was felt to need more discussion. Hence this post.
The PR is a minor change and I can't see that it has any negative consequences/side effects (very few people will disable smarty anyway), but it does mean the tplParams feature is supported with/out Smarty, which I think is valuable.
There could be nicer ways to specify such content, but this isn't a proposal about a whole new way of doing things.
Thoughts?