Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#34 | webform-export_field_key-1464988-34.patch | 9.11 KB | msielski |
#30 | webform_export_field_key_1464988_30.patch | 9.09 KB | Liam Morland |
#26 | webform_export_field_key_1464988.patch | 9.09 KB | Liam Morland |
#20 | webform_export_field_key_1464988.patch | 9.08 KB | Liam Morland |
#18 | webform_export_field_key_1464988.patch | 10.84 KB | Liam Morland |
Comments
Comment #1
quicksketchYou'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.
Comment #2
vernond CreditAttribution: vernond commented@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
Comment #3
quicksketchHm, 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?
Comment #4
vernond CreditAttribution: vernond commented@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.
Comment #5
quicksketchThanks @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.
Comment #6
Pasqualleas a minimal solution add the following code to webform.report.inc after line 730
then the "Short, raw options (keys)" download will export form_keys instead of labels..
Comment #7
Pasquallefor the other option (options element module) with select component
in select.inc line 691
replace
with
Comment #8
Pasquallethe #6 #7 patch.
the "Other.." option in grid component needs to be changed also..
Comment #9
Liam MorlandThis patch contains the changes in #8 and also handles using the keys for grid components. I think this is now complete.
Comment #10
quicksketchHi 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.
Comment #11
Liam MorlandI see what you mean. The alternative is to change every implementation of _webform_csv_headers_component(). Would that be preferable from your perspective?
Comment #12
Liam MorlandThe attached patch uses
$component['export_name']
to avoid having to change$component['name']
.Comment #13
quicksketchConsidering 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.
Comment #14
Liam MorlandExporting 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?Comment #15
Liam MorlandThe 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.Comment #16
Liam MorlandAny feedback on my last patch? Thanks.
Comment #17
quicksketchLet'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.
Comment #18
Liam MorlandThanks, quicksketch. Updated patch attached, rolled against the latest 7.x-4.x-dev.
Comment #19
Liam MorlandAny feedback on my latest patch? Thanks.
Comment #20
Liam MorlandUpdated patch rolled against latest.
Comment #21
Liam MorlandAny feedback on this patch?
Comment #22
quicksketchHey 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.
Comment #23
Renee S CreditAttribution: Renee S commentedI'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.
Comment #24
Renee S CreditAttribution: Renee S commentedOne note, @Liam Morland, last change in the webform.api.php file:
$options['header_keys']
should be$export_options['header_keys']
, non?Comment #25
Liam MorlandYes, your change looks right.
Comment #26
Liam MorlandReroll with change in #24.
Comment #27
jonkap CreditAttribution: jonkap commentedCan 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.
Comment #28
AFowleI'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.
Comment #29
Liam MorlandThe patch in #26 will apply to 7.x-3.19.
Comment #30
Liam MorlandReroll.
Comment #31
quicksketchThanks @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!
Comment #32
Liam MorlandThanks very much!
Comment #34
msielskiI 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.