Node tokens should be available in select component option labels

I actually think this is possible... but only in the 4.x branch because it has full token support. To do this, set up a select list with the two options:

0|[node:field_date:delta:0]
1|[node:field_date:delta:1]

I think that would display the first field value as the label of the first choice and the second field value as the second choice, but I'm not 100% sure you can do that, accessing individual delta values. You definitely could do it if the two date fields were separate. Unfortunately this definitely won't work in the 3.x branch. The only option there is to use hook_form_alter() to inject the choices, but that generally won't have an effect on the sent e-mails, viewing submissions, etc. so it's not a real good option.

Hi @knalstaaf, thanks for trying out the new version. So I think this *should* work, but after looking at the code I can tell why it's not. The _webform_select_options_from_text() function is where token-replacement happens, but it doesn't have access to the $node object, which is necessary to replace the field tokens.

To fix this problem, I think we should separate the token replacement from the _webform_select_options_from_text() function, and run webform_token_replace() on each of the labels. I'm moving this to a bug, since at least we shouldn't be saying you can use node tokens in the dialog browser if it's not really available.

Here is my go at a patch for this.

I just did what you suggested quicksketch. Moved webform_replace_tokens from _webform_select_options_from_text() to _webform_render_select().

Thanks @thechanceg! This looks great, exactly what I had in mind.

The only problem here is that we should wrap the token replacement here:

+  foreach ($options as $key => $option) {
+    $options[$key] = webform_replace_tokens($option, $node);
+  }

There should be an if ($filter) { } check around that. I know the $filter parameter isn't well-understood, but it's used when we want to display the element or results with the raw tokens in place instead of being replaced (e.g. in form builder or on a settings page).

Thanks for the clarification @quicksketch. I can see how that would be necessary.

Here is a revised patch. Now with 100% fewer spelling errors in the description!

The patch works for me. The code looks sane, and has quicksketch's prior approval for the approach, so I think RTBC.

This patch still needed work because it didn't take into account any of the following:

- Because the $filter option is no longer used in several functions, it should be removed from the argument list.
- Because $filter isn't used in option callbacks any more, it should be removed from the webform.api.php documentation as well.
- The patch only affected node tokens when rendering the form, but not in table, analysis, or csv downloads.
- We didn't take into account Grid components which use the same callbacks for generating options lists.

I *think* this version addresses all these problems, but we should confirm that node token replacement is working in all the places we expect:

- Rendering the form.
- Rendering results and e-mails.
- Analysis, table, and CSV downloads.
- And all of the above for grid components in addition to select components.

There's at least one problem with this patch: It removes the $filter argument from _webform_select_options_callback(), but that function still tries to use it:

return $function($component, $flat, $filter, $arguments);

That function variable comes from $info[$name]['options callback'], and grepping for 'options callback' gives the following:

./includes/webform.options.inc:18:    'options callback' => 'webform_options_days',
./includes/webform.options.inc:24:    'options callback' => 'webform_options_countries',
./includes/webform.options.inc:30:    'options callback' => 'webform_options_united_states',

Each of those functions takes a $filter argument, but none of them uses it in any way.

Thanks @jweowu for the feedback! You're right on all counts. I've rerolled to fix these issues. Great catches.

Finally pushed this into the 7.x-4.x branch. Thanks everyone here for their work on this one.

Leaving this as fixed, but want to add a note in case it will help others.

If you are using the Values module to provide select option lists, this update breaks the functionality and returns an error "Missing argument 4 for values_webform_webform_select_options()."

There is an issue filed in the Values issue queue: https://drupal.org/node/2242571

Joy

Needs porting to 8.x-4.x.

Committed and pushed 0838ce1 to 8.x-4.x. Thanks!