Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Before in Version 1.0.7 the keys for each object came in exactly as constructed as in the CSV document. Now that I have upgraded to version 1.0.8 site isn't functioning correctly because a change has now modified how those keys are brought in to the view results.
My keys used to be the following for each CSV field:
["Q1" => "43128"]
And now they are this:
["q1___value_13" => "43128"]
I use the "views_get_view_result" functionality to grab my data to do some custom work from these views and it was reliant on the capitalization and the exact key names in the CSV data. I can imagine that others might have a similar issue with this. Is there a setting in the view to tell it to leave the keys alone? If there isn't there should be. Please advise.
Steps to reproduce
Install version 1.0.7 look at the output with "views_get_view_result"
then
Install version 1.0.8 look at the output with "views_get_view_result"
Proposed resolution
Have an option that leaves the keys in place as they were without modification. For now I've been forced to downgraded my version to 1.0.7.
Issue fork views_csv_source-3503192
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
andileco commentedHi @deasly - thanks for reporting this, and apologies for the disruption...we played things a little fast and loose because it seemed like there wasn't a ton of usage yet.
The use of the aliases has some usefulness, as it allows one to add the same column multiple times and to use it for different aggregation options, etc. But we definitely understand where you are coming from. I think what we're proposing is to have both the alias and the original column available so that you can still easily do what you're wanting without losing some of the benefits of the alias.
Please let us know what you think of this approach!
Comment #3
deasly commentedHi @andileco - No worries i totally understand. That's the growing pains of a newer module. But its definitely a great one and have to commend you on its quality. I think the approach of having both is definitely a great one. Might want to define the downsides of using unmodified keys really well in the settings as mine is kind of a unique one i think (using the views data object directly). I imagine in the query settings having a single boolean option that states:
- Leave header keys unmodified in Views Object. (Disclaimer: this will disable your ability to have this functionality that the module provides and explain that functionality here.)
Or something like that. Then have it unchecked by default so that new users of the module don't miss out on the great new additions you add with the new setup.
Is this kinda where you were thinking of going? If i can help the thought process out any let me know.
P.S. I wish i had this module way back in Drupal 6 lol.
Comment #5
nikathoneComment #7
nikathoneHi @deasly, I didn't add a setting but now the column key should be present. You should have something like
Note that if you apply aggregation and use a field twice then it might worth get the value from the alias key instead of the column based your need. Sorry for the disruption caused by the alias addition.
Comment #8
deasly commentedHi @nikathone, This sounds good. I will probably be able to test this patch early next week. I will let you know when I do. Thanks for your work with this.
Comment #9
deasly commentedHi @nikathone, I tested this MR out and it works perfectly for my needs. I would consider this MR good to merge whenever you get the opportunity. Thanks again for your help.
Comment #11
andileco commentedThank you for reviewing, @deasly - merged!