In webform 2.x I used to just recurse through $form_values['submitted_tree'] in the webform-mail-[nid].tpl.php to output an unformatted, unindented email of machine-readable keys and their values with a linebreak after each. In 3.x, the template system looks wonderful but I've lost the ability to just throw in some PHP and hack it to my liking. %email_values formats the output, which I need to turn off.. the email is sent to another system that parses it.

I may be missing something, but was hoping someone could point me in the right direction. Thanks!

elizzle

Comments

spelcheck’s picture

spelcheck commented

I understand I can hardcode the entire template field per field using %email[key]'s but I'd like to use the include/exclude field features and have it just output the entire hierarchical structure, just without formatting, indenting and without pretty field names.

quicksketch’s picture

quicksketch
he/him
commented

Your best best may be to override the theme_webform_element_text() function, which is responsible for both the labels in the e-mail and the indentation. You can't use %email_values without having it run through that function. If you want just the values you can use %value instead of %email, though you still have to manually print out every field. When it comes to PHP code, you still have an array of values, but it's now in the $submission object and it's not hierarchical.

spelcheck’s picture

spelcheck commented

quicksketch, for the life of me I can't figure out how/where theme_webform_element_text is called.. is the call to the function pieced together somewhere? I'm trying to create a separate theme_webform_element_data based on the original. Thank you for the help and quick response!

quicksketch’s picture

quicksketch
he/him
commented

It's pretty convoluted how this function is called. Basically it's something like this:

- Webform builds a FormAPI structure for the *display* of the result, building up a "renderable" array (very similar to D7)
- Each element (a component's display result) is given a #theme_wrapper property of "webform_element_text" (again, based on paradigms in D7)
- The element's theme wrappers are applied during the #after_build processess, which is done by the webform_element_wrapper() function in Drupal 6, and is done automatically by core in Drupal 7.

So basically, this function is a Drupal 7 #theme_wrapper, backported in a way to Drupal 6. This means that it is a theme function tied to the FormAPI (also known as the generic "renderables" concept in D7). I don't think knowing where or how it's called will be particularly helpful, just think of it as the "wrapper" around a result. You get the value to be displayed, and this function is responsible for adding a label to the value in a label and indenting a set of values if it's a fieldset.

spelcheck’s picture

spelcheck commented

Right on! It's great having you in the forums today. I've managed to add another %email_unformatted token that uses its own theme_webform_element_unformatted() function, now I'm just trying to snag the machine-readable field key instead of the title. Inside of theme_webform_element_text() how would the field_key be called? or would I need to pass it earlier on in the process, like passing it to webform_component_invoke() and catching it in the component.inc file?

quicksketch’s picture

quicksketch
he/him
commented

I think that all components can be referenced from $element['#webform_component'], though if you want the machine name you can just grab end($element['#parents']) and that is the form_key.

spelcheck’s picture

spelcheck commented

That did the trick. Do you think this is worth creating and posting a patch? At very least it would supply the foundation for someone to create and alternate format while leaving the original theme_webform_element_text() alone. Thanks again for your help, quicksketch.

quicksketch’s picture

quicksketch
he/him
commented

Hmm, generally I'm not interested in providing an "unformatted" tree, considering it's limited use. We already have a good number of tokens, adding one that would have limitted use seems questionable. Overriding the theme function seems like it would be the correct way to handle things.

spelcheck’s picture

spelcheck commented

Sounds good. The 3.x branch looks great keep up the good work!

quicksketch’s picture

quicksketch
he/him
commented
Category: feature » support
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.