Keyword modifiers in custom form emails

(Lisa) #1


I’m having a world of troubles with keyword modifiers in custom form emails in the “Email options” screen because of the WYSIWYG editor.

Any tips on how to get a keyword modifier to not be encoded by the editor when used in an attribute?
e.g. the carat in this
<a href="somelink?edit=%response_99587_q1^as_asset:asset_metadata_thing%">
gets encoded to this:
<a href="somelink?edit=%response_99587_q1%5Eas_asset:asset_metadata_thing%">
when I commit/save the email.

Cheers in advance.

Matrix Version:

(Harinder Singh) #2

Not sure if it is a bug or it seems like default WYSIWYG(Viper) behavior.

Keyword works in Text bodycopy in email option but it is not rendering HTML tags.

I tried couple of solutions with Triggers but none of them are helping in achieving the expected result by this keyword.

(Harinder Singh) #3

I managed to achieve it via following steps:

  • Set Text field value in form action as parameter. When you submit it will go as Get variable
  • Setup a trigger with “Send Email Trigger Action”
  • In trigger action, Select a standard page in “Asset to Send”
  • Use Raw HTML container type in Standard page and write your email format.
  • Use Get variable keyword in the container.

Let me know if you require screenshots for this implementation.

(Lisa) #4

Hi Harinder, thanks for your suggestions. I see how there’d be more flexibility using a standard page but it would be a shame to not have access to all the form responses. (Unless you’re suggesting to pass the submission asset ID to the page, would that even work?)

The better solution here would be for custom form emails to allow switching from WYSIWYG to code and allowing conditional keywords… but I guess we have to work with what we’ve got.

(Harinder Singh) #5

I agree, it will be then very customised solution to include all the responses.

It will be great to have RAW HTML option available to manually format the email or have this feature available in WYSIWYG. I noticed that it is happening globally in all WYSIWYG containers.

Squiz folks will be best to advise on it. May be @Bart

(Adeel) #6

Hi Harinder,

I would also like to try this solution. Can you please share some screenshots? And also the get variables syntax you have used to print form input data in the email.


(Bart Banda) #7

Hey guys, yes, this is a known problem that is in our backlog to solve.

One thing you can do is to nest in a standard page using %globals_asset_contents_raw:1234% and in that standard page, use code container, and use the %globals_post_X% keywords to fill in the values in the email template.

(Harinder Singh) #8

Asset to Send

Trigger Setup

(Harinder Singh) #9

I will try with Bart’s suggestion also and leave my comment.

(Mark Graham) #10

We recently came across a problem similar to this. We used some keyword modifiers to fix our issue.

%response_9876_q6^tag:a href="{globals_asset_url:1234}?id={form_submission_id^base64encode}"%

response_9876 is a field on the form (a date specifically).
globals_asset_url:1234 is the page we want them to end up on
form_submission_id is the submission id that we want to transform for safety.