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.

Comments

quicksketch’s picture

Status: Needs review » Needs work

This 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.

quicksketch’s picture

marcvangend’s picture

@#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.

quicksketch’s picture

If needing to access %post[submitted][name], we should make it so Webform supports nested arrays.

What 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.

marcvangend’s picture

OK, 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.

domesticat’s picture

I'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

mnp’s picture

hi
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

ckng’s picture

subscribing.

quicksketch’s picture

quicksketch’s picture

Version: 5.x-2.x-dev »

Moving 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.

quicksketch’s picture

Status: Needs work » Fixed
StatusFileSize
new5.91 KB

Though 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.

quicksketch’s picture

Title: Introducing %submitted token to load submitted values » Introducing %value (previously %submitted) token to load submitted values
roball’s picture

The 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:

On %date, %profile[profile_firstname] %profile[profile_lastname]
claimed for %value[costs][total_costs][total_reimbursement] reimbursement at
%submission_url

The submitted values are:

%email_values

Thank you quicksketch!

Status: Fixed » Closed (fixed)

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

mlmoseley’s picture

Version: » 6.x-2.9
StatusFileSize
new6.96 KB

I have tried applying this patch to webform.module,v 1.124.2.102. It fails with the following message.

patching file webform.module
Hunk #1 FAILED at 2089.
Hunk #2 FAILED at 2270.

The .rej file is attached. Any help would be appreciated.

roball’s picture

Version: 6.x-2.9 » 6.x-3.x-dev

The patch can only be applied to the 3.x branch.

drupup’s picture

Has 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.

jeffschuler’s picture

@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.

johnnydigit’s picture

This 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?

mayhtike’s picture

Thanks

matt b’s picture

Thanks - this is perfect! Webform rocks - keep up the good work!

dandaman’s picture

I, 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?