5.4.3.1
Hi guys,
have there been any issues with keyword modifiers in email receipts reported? Since our upgrade last year there is reports of issues with the receipts using keyword modifier,
but get this - it seems only if you make a change on the email screen of the form.
They were fine as long as you didn’t touch them.
any ideas?
@rugi FYI
Not really, but also not 100% sure what you mean?
Can you describe the problem a bit more and how to replicate?
it seems in the email options for recipient email the % is being stripped?
example:
%response_1821068_q5^replace_keywords:notempty:
but in the receipts it just prints {response_1821068_q5}
I’ll get my colleague to articulate. I do know that a txt file is used to copy content into the email screen ( and keywords apparently don’t work form a txt file - but it’s only used for copy and pasting.
in the source view it also trys to wrap p tags
**<p>**<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="viewport" content="width=device-width">
<style type="text/css">
body {padding: 0;margin: 0;min-width: 100%;background-color: #ffffff;font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;}#wrapper {margin-left: auto;margin-right: auto;background-color: #ffffff;width: 620px;border-bottom: none;}h1 {font-size: 26px;color: #444444;}h2 {font-size: 22px;color:
#555555;}h3 {color: #FF530D;}table {border-collapse: collapse;border-spacing: 0;width: 600px;border-bottom: 2px solid #d3d3d3;}.error {color: #FF530D;}.question {width: 30%;text-align: right;padding: 10px;}.pad {padding: 10px;}.list {padding: 10px;border-bottom: 1px dashed #999999;}
</style>
**</p>**Ooo I can also see this has been a feature request as part of this post Conditional keywords in eCommerce form email options not working
We have also tried printing Raw contents of another asset - which it prints - but won’t populate any of the fields.
I’ve voted on this one too but it doesn’t look like it has got legs. It would be so great to have RAW body copies as part of the email options
Hi everyone,
to get around this we created a new user and applied it to the form assets, and adjusted the user preferences to display the legacy WYSIWYG tools. We still found though if you touched anything on the email options screen ( email address) it would bugger up the code still. Its a bit of a hack, but works ok.
Sounds like there is just additional HTML tags that are getting added around your keyword.
WHat would be nice is if we could change the mandatory WYSIWYG content editing area to a raw HTML block so that users can choose which version they want to use to format the email bodycopy.
Yep and I see that it’s already on Squiz map as an item for discussion. I think Charlie was interested too.
Our workaround has worked for the meantime but defo not ideal as long term.