I was recently working on a site with a multipage webform in it. I needed a value from the first page to be 'reused' as default value for a field on the second page. However the webform tokens did not allow me to access the $_POST['submitted'] array where the submitted values are stored. The %post[key] token only provides access to the values on the first level of the array; %post[submitted][name] returns the string "Array[name]" as default value for the field.
I solved this problem by introducing a new token %submitted - see patch. I patched against 5.x because I'm using D5, but since it's only one line of code, I shouldn't be to hard to port this to 6.x :-)
A more abstract way of solving the problem would be to rewrite the token filter to allow nested arrays, so %post[submitted][name] will be interpreted as $_POST['submitted']['name']. However I doubt if this level of abstraction is actually needed for the webform module.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | webform.module.rej_.txt | 6.96 KB | mlmoseley |
| #15 | webform_profile_tokens.patch | 5.91 KB | quicksketch |
| webform_token_submitted.patch | 407 bytes | marcvangend |
Comments
Comment #1
quicksketchThis doesn't seem right to me. %submitted should probably be a token that uses the actual form values that are ultimately submitted, not the ones available in $_POST. If a user had a multiple-page form, %submitted would only contain the values of the last page of the form, not all the values of the entire form. If needing to access %post[submitted][name], we should make it so Webform supports nested arrays.
Comment #2
quicksketchYou might also look at #112538: Referring to user submitted values in subject
Comment #3
marcvangend@#1: I added the %submitted token to re-use a submitted value from the first page on the second page. That is before the complete form is submitted. So how can you access "the actual form values that are ultimately submitted" at that point in time?
Of course it would be great if you can load the values submitted all on previous pages, not just one. Right now, there is a workaround for that: passing on a submitted value from the first page to the third by using a hidden field on the second page. But that is far from ideal.
Anyway, it sounds as if you're solving a bigger problem than I am. I needed this %submitted token and I think it would not harm anyone if it the patch is committed. However, if you want to work on the patch first, please be my guest and tell me if I can help.
Comment #4
quicksketchWhat is needed for your particular situation is array support within the $_POST variable, since that's really what you're working with. I won't commit the patch as-is because it's not truly the submitted values.
Comment #5
marcvangendOK, I see your point there, to call this token '%submitted' would be misleading (even though the array is $_POST['submitted']). If I have the time, I may try to write a patch for array support.
Comment #6
domesticat commentedI've posted a first-stab attempt at a patch for this against 6.x-2.3 in #112538: Referring to user submitted values in subject
Comment #7
mnp commentedhi
im using webform6.2 version with this version submitted token is not working.im getting error as
warning: Invalid argument supplied for foreach() in webform.module on line 2109.
i had 3 forms
i want to use the first form name component submitted value in the second form
how to use ?
is there any other token or i need to write some code.
please help me
Comment #8
ckngsubscribing.
Comment #13
quicksketchMarked as duplicates:
#112538: Referring to user submitted values in subject
#410886: Sender name using fields
Comment #14
quicksketchMoving to 3.x. We now have a mechanism in 3.x to support tree structures in our tokens, which we're already using for the new %email[fieldset_a][value_b] tokens.
Comment #15
quicksketchThough I didn't really intend to bundle this with another issue, I've added this functionality with the attached patch. It also includes a fix for #707278: %profile[key] token does not work in E-mail template unless form contains a %profile[key] value, making it longer than necessary.
In the end I decided to actually name this token just simply %value instead of %submitted, because %value is more generally understood. The name %submitted refers to an internal property within Webform that most users will not even be aware of.
Comment #16
quicksketchComment #17
roball commentedThe new %value[key] token is very useful! I have just tested it and it's working fine :-)
For those who are interested, I am using a webform for participants of a meeting who may claim for cost reimbursement. Thus my current E-mail template looks like this:
Thank you quicksketch!
Comment #19
mlmoseley commentedI have tried applying this patch to webform.module,v 1.124.2.102. It fails with the following message.
The .rej file is attached. Any help would be appreciated.
Comment #20
roball commentedThe patch can only be applied to the 3.x branch.
Comment #21
drupup commentedHas this been rolled in to the current version? I've installed 6.x-3.9, and it appears the patch code is part of the .module file, but I don't appear to have access to the %value token.
Comment #23
jeffschuler@drupup: The functionality exists in 6.x-3.9, but there's no token text to tell you so; an undocumented feature. Try using %value[key] in your custom subject.
Comment #24
johnnydigit commentedThis doesn't seem to work in the context described in the issue. I've looked at the _webform_filter_values function and the %value token only appears to be available for email functionality. The issue reported here was to make the %value token available on the webform itself for default values on subsequent pages. To further complicate the issue, when I'm poking around inside some custom component code, it doesn't look like I would have access to an array for the $submission parameter, even if the token were provided for that context. What am I missing?
Comment #25
mayhtike commentedThanks
Comment #26
matt bThanks - this is perfect! Webform rocks - keep up the good work!
Comment #27
dandaman commentedI, like johnnydigit in #24, would love to have the %values work on multi-page forms where the %values are all the submitted values of the previous pages. Should we create another issue for that? Any thoughts as to why this isn't done right now? Would it be that hard?