Couldn't find an issue on this.

There doesn't seem to be anything in the UI for exporting the field_key instead of the labels, i think it would make a good feature, particularly for those who are exporting the data in order to export it into another system.

Comments

quicksketch’s picture

You're right, I don't think there is an existing request for this. I'm a little skeptical of widespread usefulness, if you're doing a data import, you may need to only do it once. And if you're doing a constant migration, using CSVs probably isn't the best way (or you'd need to do data massaging every time anyway). And in most cases, import systems allow you to map column names freely anyway.

vernond’s picture

@kevinwalsh: The webform import project (http://drupal.org/project/webform_import) let's you download a template csv with field keys as column headings. This is valuable as webform field keys are unique whereas field labels are not necessarily unique.

You'd need to:
* download a webform import template using field keys as column headings;
* download submitted data using standard webform download;
* remove the submission meta-data columns from webform download;
* replace the webform column headings with those from the webform import template.

If you plan to use webform import to re-import the data on another webform and you have a bunch of grid and/or multi-select components, you would also need to get the key values of all of the selections into a single cell (also comma separated). I submitted a patch for the 7.x version of webform import to help with D7 port here: http://drupal.org/node/1219228

quicksketch’s picture

This is valuable as webform field keys are unique whereas field labels are not necessarily unique.

Hm, that's something I hadn't necessarily thought of when I posted above. What do you think @vernond, does this seem esoteric so that it should be left to other modules, or an option we should include in the core module?

vernond’s picture

@quicksketch - it's probably something we could include in webform core, but with over 180K reported installs, this is the first such request we've had in the last 2 years that I can recall. IMO we could add this to a nice-to-have list of to-do's.

If/when we do decide to implement, we should also consider moving the "Add parent name to download column headings" (http://drupal.org/node/1436790) request stuff into the various _webform_csv_headers_component() functions at the same time, adding header options into the $options array at the call from webform_results_download(). We would then have a COLUMN HEADER OPTIONS fieldset on the download page where these could be selected, thereby maintaining the current behaviour as default.

In short, I'm suggesting a new and unifying discussion/issue around "Column header options that would make webform download better" with this and parent names as a starting point (I've not taken the trouble to search past issues to look for other candidates). There may be additional nice-to-haves that folks have wanted/considered/needed, but not yet given voice to, that we could include in one job of work rather than tackling it piecemeal.

quicksketch’s picture

Thanks @vernond. An alternative I mentioned in #1436790: Add parent name to download column headings, rather than having any additional options which may be esoteric, we could provide the option to change it through theming, since that's what the theme layer is really for after all. #298784: Run CSV downloads through theme functions.

Pasqualle’s picture

Version:7.x-3.16» 7.x-3.17

as a minimal solution add the following code to webform.report.inc after line 730

line 730: if (webform_component_feature($component['type'], 'csv')) {
<?php
       
if ($options['select_keys']) {
         
$component['name'] = $component['form_key'];
        }
?>

then the "Short, raw options (keys)" download will export form_keys instead of labels..

Pasqualle’s picture

for the other option (options element module) with select component
in select.inc line 691
replace

<?php
$other_label
= !empty($component['extra']['other_text']) ? check_plain($component['extra']['other_text']) : t('Other...');
?>

with

<?php
     
if ($export_options['select_keys']) {
       
$other_label = $component['name'] . '_other';
      }
      else {
       
$other_label = !empty($component['extra']['other_text']) ? check_plain($component['extra']['other_text']) : t('Other...');
      }
?>
Pasqualle’s picture

Status:Active» Needs work
StatusFileSize
new2.25 KB

the #6 #7 patch.
the "Other.." option in grid component needs to be changed also..

Liam Morland’s picture

Title:Export field_key instead of labels?» Export field_key instead of labels
Version:7.x-3.17» 7.x-3.x-dev
Component:Miscellaneous» Code
Status:Needs work» Needs review
StatusFileSize
new1.98 KB

This patch contains the changes in #8 and also handles using the keys for grid components. I think this is now complete.

quicksketch’s picture

Hi Liam, thanks again for the patch.

This segment of code is ugly. The "name" is the label of the field, overwriting it just use the form key makes our data inconsistent in the download hooks.

+        if ($options['select_keys']) {
+          $component['name'] = $component['form_key'];
+        }
Liam Morland’s picture

I see what you mean. The alternative is to change every implementation of _webform_csv_headers_component(). Would that be preferable from your perspective?

Liam Morland’s picture

StatusFileSize
new6.27 KB

The attached patch uses $component['export_name'] to avoid having to change $component['name'].

quicksketch’s picture

The alternative is to change every implementation of _webform_csv_headers_component(). Would that be preferable from your perspective?

Considering we're already doing some checking for $export_options['select_keys'] in the select and grid components anyway, yes I think it would be preferable to update all the _webform_csv_headers_component() implementations. Right now a $component is a $component, and it always has the same keys and values in it. I'd prefer to avoid having it sometimes contain special information.

I'm also not 100% on if we should be using the existing "select_keys" option to determine if form keys are used instead of labels. It's certainly similar, but the UI does not imply that it would have such an effect. Though I haven't had a need to export select list keys myself either, so I'm not really clear on what the use-cases here are, and if people who export keys would always want everything as keys or not.

Liam Morland’s picture

Exporting as form keys makes it much easier to create systems which import the CSV files generated by Webform.

It wouldn't hurt to have separate configuration option for keys in the headers. I think people who want keys in their selects probably want keys in their headers too. If it is decided to have a separate config, I would be happy to write the patch.

Is it OK to use $component['export_name'] as in the patch in #12?

Liam Morland’s picture

StatusFileSize
new10.93 KB

The attached patch has a separate option for choosing Field Keys instead of Labels. It also uses keys for the Submission Details and updates webform.api.php (in the process of which some end-of-line whitespace was stripped).

This patch still uses $component['export_name']. If you don't want this added, let me know and I will move that logic into each component.

Liam Morland’s picture

Any feedback on my last patch? Thanks.

quicksketch’s picture

Let's use the $export_options in all of the callbacks, rather than introducing a new pseudo property into the $component variable. Right now $component variables are consistent throughout all Webform; it'd be a shame to start throwing in properties that are sometimes there and sometimes not.

The excerpt from the select component is a good example, even though it's more code.

Liam Morland’s picture

Version:7.x-3.x-dev» 7.x-4.x-dev
StatusFileSize
new10.84 KB

Thanks, quicksketch. Updated patch attached, rolled against the latest 7.x-4.x-dev.

Liam Morland’s picture

Any feedback on my latest patch? Thanks.

Liam Morland’s picture

StatusFileSize
new9.08 KB

Updated patch rolled against latest.

Liam Morland’s picture

Any feedback on this patch?

quicksketch’s picture

Hey Liam, still a little skeptical and I feel like this is lower priority. I don't feel like most users of Webform understand field keys to begin with so I'm hesitant adding more features that highlight them. With Options Element I've tried to hide them as much as possible. I'll get to this one next time I'm going through the entire "needs review" queue for Webform.

Renee S’s picture

I've wanted this FOREVER. Every single time I export results for analysis I (or my users) have to go in and figure out what non-unique labels refer to which columns. It's a giant pain. I'm mostly still on D6, though I'd like to give a shot at backporting this once it's good for D7.

Renee S’s picture

One note, @Liam Morland, last change in the webform.api.php file:

$options['header_keys'] should be $export_options['header_keys'], non?

Liam Morland’s picture

Yes, your change looks right.

Liam Morland’s picture

StatusFileSize
new9.09 KB

Reroll with change in #24.

jonkap’s picture

Can this patch be applied to version = "7.x-3.18"?

Adding my plea for permanent integration of this patch: I am using Webform for research in which I am implementing a survey that contains dozens of sentence-long questions in a Grid. Exporting the keys for the questions in the Grid would make things so much more practical. Replacing questions by their keys is essential to conduct analyses is statistics software.

AFowle’s picture

I'd like to download field_keys instead of the questions just because they are so much shorter, to answer #1. It makes fora much tidier spreadsheet to work with.

I think I should have seen my bug report #1931842: Grid's custom keys not shown as column headers when downloading grid to file as a variant of this request.

Liam Morland’s picture

The patch in #26 will apply to 7.x-3.19.

Liam Morland’s picture

StatusFileSize
new9.09 KB

Reroll.

quicksketch’s picture

Status:Needs review» Fixed

Thanks @LiamMorland and Pasqualle. Seems solid enough to me. I think it's a bit esoteric still (even more so now that Options Element has some popularity), but given the additional input here I think it's been justified. Committed as-is to the 4.x branch. Thanks!

Liam Morland’s picture

Thanks very much!

Status:Fixed» Closed (fixed)

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

msielski’s picture

Issue summary:View changes
StatusFileSize
new9.11 KB

I don't expect 6.x to be updated to include this feature, but here's patch #30 for 6.x in case anyone needs it. This is especially useful when migrating Webform results from a d6 to d7 site as having the header keys is very useful on import.