Make Safe Key (in addition to Value) of Select Components accessible via tokens

I'm changing this to a task, since it's something I've been wanting to do for a while. I think that the key should always be used for the %value tokens for select lists, as I can't think of how the label would really be very useful.

I've also marked #1346836: Submission token problem in Webform of Drupal 7 as duplicate. I think there's another request in the queue for this issue also, if I find it I'll mark it duplicate of this one too.

quicksketch thank you for the interest.

I just ran into this issue. In line with what quicksketch changed the title to, I've added a conditional that checks if the component is a select and, if so, implodes the values from $display_element['#value'] with a comma. I'm not overly familiar with the internal workings of Webform, so this may be way too simplistic, but it appears to be working against single/multiple, optional/mandatory, and check/radio/listbox. Patch was created against 6.x-3.x

Any news about this issue?

This patch has the right idea and would probably function, but it's not inline with the way Webform is written. We can't add an IF statement checking for a certain component type right in the middle of _webform_filter_values(). Ideally, we could confine the changes to the select.inc component only, but I'm not sure if that's possible.

If we stick with the current route, we'd need to introduce a new property into hook_webform_component_info() for the select component, like "output_raw_value" or something. Then in _webform_filter_values() check if the component has that property by using webform_component_feature($component['type'], 'output_raw_value'). This would make it so other components besides just select could output raw values (such as the grid component or custom components added by other modules).

I think there's another request in the queue for this issue also, if I find it I'll mark it duplicate of this one too.

I finally found it. Marked #749782: Select Option 'safe_key' to display in email template? duplicate.

I'm not sure that putting the safe_key into the email in place of the readable option is a good idea.. Maybe if there were a per-form option to do so, but I think it would make most sense to present the human-readable option in the emails that get sent out. For example, say you had node nid's as the safe_key but had node titles as the readable option and you're sending emails out to a client. They wouldn't want to see an nid in the email, no?

Just my thoughts.. I ran into a problem where I had not set up a hook properly and was getting safe_key values in my emails, which made them difficult for client email recipients to make sense of the options that had been selected.

For example, say you had node nid's as the safe_key but had node titles as the readable option and you're sending emails out to a client. They wouldn't want to see an nid in the email, no?

For this purpose, wouldn't the %email tokens be suitable? True they include the label also.

Checking in on this.
Have a need to get the selected options value for URL redirection. any news?

Thx

Will there be any update for this soon? Or should we use jbylsma's patch?
I ask because I'm delaying one major change in my Drupal 7 site because of this issue :)

Thank you.

The patch is for webform 6.x I think

tested #3 jbylsma's patch works for 7.x-3.15.

I checked 7.x-3.15+25-dev.
Still this bug exists.

Still this bug exists.

Yes, there hasn't been a comment saying it's been fixed yet. The current patch needs work per my comments in #5.

Looking for this as well.

There is a workaround #236515: Accessing form values from confirmation message box
Though this requires using PHP Input Format or creating a custom block to access the values, etc.

This probably won't be changed int 3.x, but we built-in some consideration for it as part of #1001798: Rewrite token replacement system to use D7 tokens, which is committed to the 4.x branch.

In 4.x, we'll be able to do a token such as [submission:values:component_form_key:key] or perhaps [submission:values:component_form_key:raw] to get the key of select lists. This feature is still not implemented, but most of the pinnings are there for adding this functionality at this point.

I needed this for D6. Here's a that seems to work for me, uses %safe_key[key]. For select inputs, multiple values are concatenated. This is useful for views arguments. I'll see if I can roll something similar for 7.x-3.x.

Regarding #16, since "most of the pinnings are there," maybe another is issue is appropriate for the 4.x feature request since I believe this patch fulfills the original issue intent.

Okay, here's the D7 version. Basically the same with some line number differences.

Regarding #16, since "most of the pinnings are there," maybe another is issue is appropriate for the 4.x feature request since I believe this patch fulfills the original issue intent.

Hm, okay well fair enough, but we can't commit this patch now until the functionality is added to 4.x with an upgrade path.

Attached is a patch that includes #18 plus support for a formatted email_safe_key

Here's my patch for the 4.x version. Not sure if this is the way to go, but it's working for me right now.
[EDIT: THIS PATCH HAS A TYPO. SEE PATCH FROM #22]

Fixed typo in patch submitted above.

Thank you for the patch :-p Just applied #18 to 7.x-3.18. I was redirecting to PayPal and passing one of the SELECT fields as a value in the URL. The value of the field as displayed to the user was "Premier ($99.99/month)", but I really only needed the safe key, "Premier", for the URL. The added %safe_key token worked like a charm :-p

Patch #18 tested and working.

I would like to advocate for using #20 rather than just #18.

#20 doesn't work with the the select_or_other module installed. It's fine if one of the predefined options are selected, but if the 'other' option is selected and a value entered, then safe_key[key] is empty.

@Matt B, what's your desired output? The select_or_other value comes from a text field when "Other" is selected, so there's not really any key, just a value. The predefined options are all key-value pairs, but "Other" is just a trigger to display the user input field. The word "Other" could be output in place of a key, but is that what you're expecting?

@thirdender - I had select options of
5|£5
10|£10
20|£20
50|£50
100|£100
Other £

In a field called amount.

%safe_key[amount] will output '5' if the user selects £5 (etc). If the user selects Other and enters '25' then %safe_key[amount] should output '25'.

It looks like @gbrands added a patch in #22 which adds the same functionality to 7.x-4.x, but there's still no upgrade path from previous versions. Handling Select or Other properly would be beneficial also per the pattern supplied in #28.

The patch from #22 is functional in 7.x-4.0-alpha8, but gives the following warning on the confirmation page:

Notice: Undefined index: #options in theme_webform_display_select() (line 557 of /var/www/mainweb/sites/all/modules/webform/components/select.inc).
Warning: Invalid argument supplied for foreach() in theme_webform_display_select() (line 557 of /var/www/mainweb/sites/all/modules/webform/components/select.inc).
Notice: Undefined index: #options in theme_webform_display_select() (line 557 of /var/www/mainweb/sites/all/modules/webform/components/select.inc).
Warning: Invalid argument supplied for foreach() in theme_webform_display_select() (line 557 of /var/www/mainweb/sites/all/modules/webform/components/select.inc).
Notice: Undefined index: #options in theme_webform_display_select() (line 557 of /var/www/mainweb/sites/all/modules/webform/components/select.inc).
Warning: Invalid argument supplied for foreach() in theme_webform_display_select() (line 557 of /var/www/mainweb/sites/all/modules/webform/components/select.inc).

Any ideas what to do about that? Is there a parallel development or another option for retrieving a select list key?

subscribe

It looks like @gbrands added a patch in #22 which adds the same functionality to 7.x-4.x, but there's still no upgrade path from previous versions. Handling Select or Other properly would be beneficial also per the pattern supplied in #28.

I"m not sure what my qualm was here. It's fine if we add the feature to 7.x-4.x without an upgrade path. We just can't add it to the 3.x versions without an upgrade path. I'm going to move this into the needs review queue so I take a look at it sooner. I think the 7.x-4.x patch is 95% there.

Thanks @ben_r for this new report on using select lists on confirmation pages. I'll take a look at that part too.

The patch in #22 looks like a good start, but I don't think the implementation is entirely correct:

+              // Remove theme wrappers and options for key modifier
+              elseif ($modifier === 'key') {
+                unset($display_element['#options']);
+                $display_element['#theme_wrappers'] = array();
+              }

I'm surprised that would work. I suppose it falls back because of the select_or_other integration that just prints the value if no options match. It might be better to check $element['#value'] directly here. It seems less likely to break that way too. This patch needs a reroll because of #2038371: Create a better naming scheme for our tokens [submission:values:x]

I applied patch #17 to my D6 install. Finding the intersection of the keys in the option array with the values did not work, because the options on this form were grouped -- 2xdimension array. Not sure how to fix it right, but for now I'm just imploding the values and applying that to the safe key token.

subscribe

I rerolled #22 like #33 said. I didn't have much time so I couldn't look into what @quicksketch was saying about $element['#value'].

I did get rid of the warnings mentioned in #30 though.

The patch in #36 is for 7.x-4.x.

I modified #36 to generate the safe value of the key. This works only on select components. If multiple selection is enabled, the keys are strung together with spaces separating them.

This concept could be extended to grids, dates, times, etc.

This is awesome! Thanks @DanChadwick!

Very the extremely unlikely off-chance somebody needs this as much as I did:

Here's a re-roll of #18 against the latest 7.x-3.x