When I used version 2.x I was able to have completely custom email templates for each form. This was important because a third party system parsed emails and imported submissions into its own database. With version 3.x I lost this ability. I can include a cycle that pairs keys, names and values from $node and $submission objects, as well as converts extra items into arrays and gets the final values. Then I can use the new variables in the template to format my emails the way I need, but is there another way of doing that? It seems wrong to use the same cycle in each email template. Thoughts?
P.S. I was trying to use the hook_webform_submission_presave to run the cycle and add another array inside the $submission object, but that didn't seem to work. Not sure why.
Comments
Comment #1
quicksketchI'm not clear on what is "not possible" in 3.x. Just like in 2.x, you can create individual templates for your e-mails. Instructions have been updated in THEMING.txt, you can follow those. The only difference is that the $submission object is now always keyed by component ID instead of form key. This is for consistency of the data throughout Webform, which always uses component ID in all places now instead of a mix of sometimes component ID and sometimes form key.
Comment #2
bradjones1I wrote a blog post on what I think is this issue, recently. The "cycle" referred to in this ticket is likely something similar to:
That gives you a hierarchical
$treeof webform submitted data.I do think there's opportunity for improvement here: What if equivalent logic could be performed by Webform in a quick helper function, then passed through theme() into the template? quicksketch is right - the information is there, just not in the most usable form.
Put another way - there was good reason to switch to the current data structure internally, but this information can be re-worked into a more accessible form for file themers.
I'd expect more novice users would have an easier time with something like
print $submitted_array['key']['value'] ;than matching the key and value on their own.If there is consensus that this is a good way to proceed, I can whip up a quick patch that puts this into webform.submissions.inc.
Comment #3
quicksketchPlease open a new issue (reference this one if desired) if you decide to come up with a patch. At this point I don't think it's likely that we'll change the templating system in the 3.x branch to retain compatibility with sites already using the current version of Webform.