Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
In #273837: Views Integration for Webform we added Views integration for the webform_submissions table, which allows you to make listings of submissions by a particular user. However there currently is no way to actually show individual submissions or make listings of them. The reason for this is several technical challenges with the way Webform stores its data (one large table with several rows per submission or even per field). It might be possible to adapt the Webform schema to support Views better, but this request might be on the long-term wishlist.
Comment | File | Size | Author |
---|---|---|---|
#233 | 680386-7_3-views_integration_220-233.patch | 19.93 KB | Spokje |
#231 | webform-680386-231.patch | 15.17 KB | c4rl |
#220 | webform_views_submitted_data.patch | 21.49 KB | quicksketch |
#219 | webform_views_submitted_data.patch | 21.71 KB | quicksketch |
#216 | webform_views_submitted_data.patch | 17.16 KB | quicksketch |
Comments
Comment #1
joachim CreditAttribution: joachim commentedFrom what I can tell it's not a horrendous problem, just a bit ugly.
Profile module has the same problem in that its data storage is also one big long table of every field one after the other. For single valued fields, just alias the table. For things like checkboxes, write a loader handler like taxonomy does to get multiple terms as a single field.
I haven't time to devote to this right now, but this might help someone else on the right track... :)
Comment #2
jhedstromUnlike the profile module, it looks like this integration will require that each separate webform node get it's own base table definition in hook_views_data.
Comment #3
joachim CreditAttribution: joachim commentedOh blimey, yes.
Still, that's not totally infeasible. Lots of modules define things in hook_views_data based on dynamic stuff -- taxonomy, flag, nodequeue.
Maybe define a relationship that takes the webform node as a setting value (same approach as flag).
Comment #4
quicksketchAn additional problem is Webform's handling of multivalue fields, such as date, time, selects, and grids. Each of these fields creates multiple entries in the webform_submitted_table instead of just a single row like profile.module (which serializes its date values). I'm fairly sure Views can handle this too, but again it's mostly an edge case compared with every other existing implementation out there. CCK does not select multiple rows for a single value either, if you use the "Group multiple values" option in CCK Views implementation, then it does a second query in the render() method.
Comment #5
Dgrey CreditAttribution: Dgrey commentedI used table wizard module to expose the fields to views then used table view with rows/column template to transpose.
It's ugly and exposes too many fields but I can use it for now until there is a better solution.
Hope you experts can figure it out soon.
Comment #6
Summit CreditAttribution: Summit commentedSubscribing, greetings, Martijn
Comment #7
jgoodwill01 CreditAttribution: jgoodwill01 commentedDgrey,
I'm trying to do the same thing as you did but for some reason Table Wizard is not showing the "data" field in the table? Did you have this same problem?
I really need to find a way to display webform submissions in a view for an upcoming project. Does anyone have suggestions as to how this can be accomplished?
Comment #8
s7ev3n CreditAttribution: s7ev3n commentedSubscribing..
I'm using Webforms 2.9 (production site in the making) in a project but I still have the same question, how to display webform submissions you know, for admin users in a printable way...
I'm very new to drupal, but I'm developing 2 projects right now with it.. reading a lot and learning on the spot.
I'm also waiting for the 3.0 version of webform, great Job for what i've seen, congrats guys.
Comment #9
sidharth_k CreditAttribution: sidharth_k commentedSubscribing.
Comment #10
roball CreditAttribution: roball commentedComment #11
mcrittenden CreditAttribution: mcrittenden commentedSub.
Comment #12
joomlerrostov CreditAttribution: joomlerrostov commentedSubscribing too. I need display separate fields data via Views from webform.
Now i need create multiple separate webforms for each (!!!) field - because i render then his data via Views, and there is no way display each field , i can only display all webform...
Comment #13
deggertsen CreditAttribution: deggertsen commentedSubscribe. This really would make webform 100 times more useful! However, couldn't you almost just use a node type as a webform with CCK and then you would have full views support as well as user relationships, authoring information, etc. Of course the nice thing about a webform vs a node is that you can make it look better (more user friendly) and have multiple pages. Am I wrong? I mean that is basically what is explained on the module page is the difference between webform and CCK.
Comment #14
quicksketchThe difference between Webform and CCK is not the fact that you can make pages. The difference is Webform is not intended to show information publicly. CCK has a much better database storage mechanism that allows it to scale and work with Views better. Once Webform does have Views integration, I'm sure there will be no end to "my site is slow" complaints as people expose Webform results to the public, which Webform was not and is not suitable for.
Comment #15
joachim CreditAttribution: joachim commentedSudden brainwave...
Every webform has different components. Defining on the fly a Views field for every one of these components is perhaps prohibitive.
What if instead there was a single Webform submitted data field, which had in its options a selector for which webform component field it should show (in other words the cid)?
So to show the results for a single webform you might set up:
- view base table: webform_submissions
- filter on node id
- field for user / or a relationship to get to the users table
- add multiple copies of the Webform submitted data field, in which you select the component. The cid chosen in the option determines how this field joins on to webform_submitted_data.
Comment #16
tejaspmehta CreditAttribution: tejaspmehta commentedsubscribing
Comment #17
Dave Reid(totally-not-a)subscribe...
Comment #18
quicksketchHere's a first take at this functionality. It does actually work, but there are very clear limitations to what's been implemented. This patch essentially makes it possible to display Webform submission values as a View field, but it does not implement filters, sorts, or arguments. Due to the nature of Webform creating innumerable fields (multiple 500+ field webforms on a single site are not unheard of), exposing fields in the classical sense is not practical. This patch takes the approach of providing a single field for each component type, though in truth we could probably simplify this and group them by the type of data stored: text (radios, textfield, email, textarea), many-to-one (select lists and checkboxes), grids (not at all sure if we'd even do grids or how to deal with them), dates, and times. Unfortunately that's an awful lot of Views integration to be writing, but considering Webform's scope that's not really surprising.
To use:
- Create a new view of the type "webform_submissions" as the base table.
- Add a relationship for "Webform submitted data", enter the NID of the Webform whose fields will be selected.
- Add a field "Webform submitted data: [component type]", select the relationship on the first page options, then configure normally on the second page of options.
As expected, such Views integration is rather wildly inefficient, requiring a JOIN for every field added, so don't be expecting to add more than 60 fields to a single view or you'll run into the MySQL join limit.
Comment #19
eme CreditAttribution: eme commentedI was facing the eternal problem of exposing webform data in Views. And I think that a new module (still in dev) could help resolve this issue : Views Crosstab is able to push data that are normally in rows into columns (even if normally the module goal is more to do calculation like acerage/min/max/sum...).
Basically, the issue is that the way webform exposes its data is not exposable in Views as it displays an endless list (see this example : http://drupal2.emerya.fr/normal). It has an interest, though, to expose a single submission (or more, but not a long list of entries). The goal is to show it in columns with the crosstab module (example : http://drupal2.emerya.fr/crosstab). The views that is here created in a very dirty way via Table wizard to expose the datas into Views and via a View Crosstab. That view takes automatically into account all field created and any new submissions (you can test it with new entries in the form).
Objectives are : define what to show and search or filter, capability to show data (with Views cache capacity) to different roles, views multiple webform in a single views...
Issue is that it is not that easy to configure for now...so there is a lot of work here : expose datas in Views (even complicated data like Grid), finish the crosstab module... The View I created is far from being really usable and again I created it in a dirty manner...
Please tell if you think it is the write way for you to deal with it...
Comment #20
quicksketchWhile tools like TableWizard are nice in that they work with arbitrary data, we should be implementing this in the proper, supported way with Views integration built-into Webform. Webform still has a few special situations in which we'll need customized handling top properly retrieve and display information in a useful manner. The patch in #18 is already a start on this, we just need to extend its support to filters, sorts, and other types of components.
Comment #21
saintiss CreditAttribution: saintiss commentedCan I subscribe to this bug somehow, so I am notified of new developments?
Comment #22
alextronic CreditAttribution: alextronic commentedOK quicksketch I just tried your patch. Awesome! Thank you.
I had no issues with it in my tests. Good work.
Comment #23
whiklojsubscribing
Comment #24
brack11 CreditAttribution: brack11 commentedsubscribing
Comment #25
skawtus CreditAttribution: skawtus commentedsubscribing
Comment #26
bdawg8569 CreditAttribution: bdawg8569 commentedI am very interested in using this as well. I have applied the patch from post #18 and the patch works, but when i create the view i don't get any results at all, even tho i have 63 webform submissions. I should note that i am using the beta6 code, but i didn't think that would matter when looking at the release notes. I can try going back to beta5. I was wondering if anybody had any advice. I have tried to follows the steps that quicksketch outlines. I created a new view of type webform_submissions and added the relationship. I am positive that the NID for my needs is 10. I have verified that by going to node/10 rather than alias and i get to the webform just the same. After that i created just a couple of fields using the "submitted data: selectoptions" and "submitted data: textarea" components. I chose the relationship and then left all of the default options the way they were. When the view renders i only get the title of the view. Any help would be greatly appreciated. Thanks.
Brian
Comment #27
quicksketchThe current patch is in no way usable, it's just a starting point. If I remember correctly, the only type of data that works is for a "textfield" component.
Comment #28
alextronic CreditAttribution: alextronic commentedIt worked for me. It gives an error message, but I close it, try again, and it works. I know it's not even close to acceptable, but it did what I needed.
Comment #29
bdawg8569 CreditAttribution: bdawg8569 commented@alextronic - Were you using only textfield components as quicksketch mentioned?
@quicksketch - I realize that it is not usable, I was just testing it because I am looking for some sort of solution similar to this. At the time that we used webform the client didn't indicate that they would eventually want to expose the results to everyone, or we would have come up with something different.
Comment #30
bdawg8569 CreditAttribution: bdawg8569 commentedI am able to get the patch to work when i take out all the components that are not textfield or textarea.
Comment #31
attheshow CreditAttribution: attheshow commentedsubscribing
Comment #32
InfinityMark CreditAttribution: InfinityMark commentedQuickSketch,
When you say, "we added Views integration for the webform_submissions table, which allows you to make listings of submissions by a particular user," please tell me where one would go to allow this level of functionality. I need to create a list of submissions by x user and add that view to /user/x to allow them to view their submissions.
Is this a views add-on module or a web-form add-on module? I'm looking to do this exact thing but can't seem to find the right module to allow it. Please point me in the right direction!
Thanks,
Matt
Comment #33
InfinityMark CreditAttribution: InfinityMark commentedNevermind - I see how you can access your own submissions without using views. Thanks!
Comment #34
Danny Englandersubscribing
Comment #35
DanaRoseRoss CreditAttribution: DanaRoseRoss commentedsubscribing
Comment #36
MBroberg CreditAttribution: MBroberg commented@ #4
I am not a programmer by any means, but is it possible to handle this in some way by taking all of the user-entered data for a particular field and merging the responses into a single "result" field and displaying that? Perhaps this has already been discussed, or is obvious, or obviously stupid, but it makes sense to me at my preschool level of understanding of this issue.
After all, most of us are wanting views because we only need to display the end data in a searchable, filterable format, not be able to edit it. Editing can still be done at the original webform, and most of our issues are with how to display the data in usable form for admins and the user viewing results. So for example if a field asks for "child name" and a user creates multiple responses, can the children's names be merged into a list and stored as a single answer? Like Flexifield does in some way?
And then if that were done, could filters be applied using the "contains" operator?
And could sorts be done on the combined result field, using first letter of first entry?
Maybe not ideal, but it would suit me if I could just be able to make a slightly better table than Webform and Webform Report provide, mainly with a filter on any given field and/or a chance to sort by row header.
Comment #37
goose2000 CreditAttribution: goose2000 commentedSubscribe
Comment #38
akalata CreditAttribution: akalata commentedAnyone else hoping to be able to use the Feed display type with webform_submissions as the views base? It's currently available as an option, but with a missing row style plugin. Would creating a row style plugin for feed and webform_submissions be very difficult? I tried figuring it out, but it's over my head at this point. I'm hoping my agency will be able to sponsor this addition, but I can't make any promises as of yet.
My use case: I want to use RSS to generate a "ping" whenever a form is submitted, and build a dashboard-type overview that can answer the question "are forms being submitted on this site"? Since I have over 20 sites with multiple forms, logging in to check each one isn't very feasible, and neither is signing myself up to receive emails.
Comment #39
Apfel007 CreditAttribution: Apfel007 commentedsubscribe
Comment #40
jerdavisI thought of a potentially different take on this this morning that may or may not work.
We're actually using the patch above in some work right now, although as quicksketch says it's not exactly ready for prime time. One particular problem we have is with repeatability.
Our scenario is this. We have a content type that is acting as a campaign, that campaign wants to have people come and endorse or support it. Those endorsements need to be collected and then displayed along side the campaign. We chose webform for collecting the endorsements as the text and options for the endorsement need to be able to be changed between campaigns, so using an endorsement content type wasn't going to work.
The problem here is displaying the webform submissions along side the campaign. We managed to get this working with the patch provided above, but when the next campaign is created we'll start running into problems with the view configuration not lining up. The components/fields available for the submissions and the component IDs won't match so the query will be invalid.
The problem in my mind is that in order to tell the view display what webform components you want to pull and display for submissions, you need to specifically tell the view display what node's webform you'll be using. In the patch form quicksketch you do this by actually typing in the NID of the node with the webform into the relationship handler. Once that's done you can start adding fields by data type and those fields will know what components are available to the particular hard-coded webform.
This is a tough problem to get around, given that you can't pick the components you want to display and have that display be re-usable for the next webform. So you're coming back and creating a brand new view display for each webform. While this may work for some applications, it breaks in use cases like ours.
My idea to get around this is to take a different approach to configuration. Instead of using a field based row plugin and having to hard-code the webform node to find fields to add, let's move the choice of fields to the webform's configuration. Create an options page for the webform that provides display settings for submitted data, similar to the display settings on a content type. Then provide a row style plugin in views for "Webform submissions" which is informed by the display settings on the webform. You'd still need to know which webform you wanted to pull results from, but this could either be hard coded through a filter or be dynamic through a default argument handler.
Using this approach the decision about display is moved to the webform configuration, and the view can be generic and re-usable. When a new campaign is created and it's webform configured the content creator can decide which fields will show up and in what order, and the view will respect that. To add another level of flexibility it might be nice if there was a teaser and full option, or something similar, to allow to options for display when configuring the view.
I'd like some opinions on this, and if someone has the time to take a first crack at an implementation be my guest! Otherwise I'll try to work this in my schedule assuming quicksketch thinks it's viable.
Comment #41
quicksketchThis still wouldn't solve the problem that you need to pull "Component 4" from Webform A and "Component 10" from Webform B when component 4 and 10 are both used for the same purpose between each form. There's just no way to (efficiently) construct that query.
I think what you're describing is a natural limitation of Webform. You wouldn't expect that you could combine "field_summary_a" with "field_summary_b" into a single column using CCK's Views integration. Each webform's fields are entirely separate from all other webforms.
Comment #42
jerdavisI admit that I haven't fully thought through this yet, but I think - at least for our use case and those like it, it might still work.
We wouldn't be trying to merge results from different webforms, we'd be only pulling from one webform at a time.
In my use case I'd have a default argument handler that would hook us into the webform for the node we were looking at. This would be a display that's either a block displayed along side a node with a webform or a page at node/%/results. Either way, the results would be the submissions for just that webform. In my mind the query would return all submitted data for that webform, then filter which fields are displayed based on the display settings for the webform during the rendering process.
The query might just be something akin to
There's probably a couple dozen reasons why this is still either infeasible, unrecommended or insane.
Comment #43
Exploratus CreditAttribution: Exploratus commentedsubscribe
Comment #44
mschuyler CreditAttribution: mschuyler commentedsubscribe
Comment #45
easp CreditAttribution: easp commentedsubscribe
Comment #46
machete1 CreditAttribution: machete1 commentedsubscribe
Comment #47
servantleader CreditAttribution: servantleader commentedTake a look at:
http://nodeone.se/blogg/finally-webform-submission-data-in-views
He uses the webform_mysql_views and data modules.
Comment #48
quicksketchPutting this back into needs work, clearly our current patch isn't yet viable since it only works for textfields.
Comment #49
DoubleT CreditAttribution: DoubleT commentedSubscribing
Comment #50
drupov CreditAttribution: drupov commentedsubscribe
Comment #51
scotwith1tsubscribe
Comment #52
Jumoke CreditAttribution: Jumoke commentedDrupal has to supply a "subscribe" button/funtionality to posts without us having to type the word and spam good conversations with the word "subscribe" dammit
*rolling my f**ng eyes*
Comment #53
wjackson CreditAttribution: wjackson commentedsubscribing and agreeing with the above post.
Comment #54
NitebreedFollowing the screencast provided in #47 i was able to get the webform-data in views. Thank you!
Comment #55
Danny_Joris CreditAttribution: Danny_Joris commentedsubscribing
Comment #56
aaron1234nz CreditAttribution: aaron1234nz commentedsubscribe
Comment #57
aaron1234nz CreditAttribution: aaron1234nz commentedI've been thinking about how to do webforms -> views integration over the last few days and have been dabbling with various solutions. Here is a summary of my thoughts:
The problem of multiple entries per field is the biggest problem to solve.
There are three possible solutions to this:
1. Add "AND no = 0" to the criteria of each join. The benefit of this is that one database row corresponds to one form submission. The big problem with this solution is that multiple entries are not handled.
2. Use a views rows plugin to handle the multiple results per form submission (which come as a result of the multiple entries problem). This is problematic because when there are multiple results it is tricky to know which ones should be merged. A number of style plugins (such as the table plugin) would also have issues because the 'fields' row plugin more-or-less hard coded.
3. Use a special query plugin to do specialised type of query. This is only possible in views 3.x and will still suffer from some of the problems in 2
4. Use subselects rather than joins to extract the data and to perform the filter functions. This will defiantly work. I've used this approach before extracting data from key-value tables using views. The downside of this is that it will be slow under mysql. I did some explain queries and under mysql the "joins" are done with a filesort, however under postgres the subselects are actually faster than with a lots of joins (index scans vs index scans and nested loops). The downside of this approach is that mysql and postgres specific code will be needed [group_concat vs array_to_string(array())]
I think long term altering the schema of web forms is the way to go.
Comment #58
ehmprah CreditAttribution: ehmprah commented+1
Comment #59
Anonymous (not verified) CreditAttribution: Anonymous commentedWebform MySQL Views works fairly well (if buggy and pretty slow on my localhost install). The big problem is you cannot get select options out, only the key value. And also multiples I believe (as mentioned above). I put this in their queue though I don't even know if it's solve-able: http://drupal.org/node/1097996
Because of the nature of a MySQL view it's an actual query into the Webform data table (which isn't really a problem in itself). The issue comes along when you want to get stuff like option labels that are serialized into the extra field in the submitted data table since you cannot unserialize inside a MySQL query.
Comment #60
attheshow CreditAttribution: attheshow commentedGreat screencast. Thanks for posting that servantleader.
Comment #61
Kreativs CreditAttribution: Kreativs commentedsubscribe
Comment #62
toabi CreditAttribution: toabi commentedSubscribing
Comment #63
sheila8stamp CreditAttribution: sheila8stamp commentedsubscribing
Comment #64
arski CreditAttribution: arski commentedsub
Comment #65
Cristhian CreditAttribution: Cristhian commentedCheck this one http://drupal.org/project/webform_views_submitted
Comment #66
yellowlabrat CreditAttribution: yellowlabrat commentedsubscribing
Comment #67
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #68
travist CreditAttribution: travist commentedHere is a new patch with a different approach for this problem.
What I wanted was to dynamically create the fields based on the webform components. My use case was that the webform could be ever changing and I didn't want to update the view and add new fields to the views for every component that I was adding to the webform. The view needs to be an organic reflection of the webform structure, and this patch accomplishes just that.
Please let me know if this works for you.
Thanks,
Travis.
Comment #69
travist CreditAttribution: travist commentedComment #70
Jean-Philippe Fleury CreditAttribution: Jean-Philippe Fleury commentedSubscribing
Comment #71
Delty CreditAttribution: Delty commentedSubscribing
Comment #72
joachim CreditAttribution: joachim commentedthe patch sounds like an interesting approach, but it doesn't work for me I'm afraid.
If I don't specify a nid, I get:
If I do specify a nid, I get the same errors AND the preview button says:
Comment #73
travist CreditAttribution: travist commentedSo, I have been doing a lot more work on this patch. Here is the latest version that fixes many issues and also fixes the crash above.
Please try this one to see if this works better...
Comment #74
travist CreditAttribution: travist commentedComment #75
roball CreditAttribution: roball commentedWhy do you change
?
Comment #76
travist CreditAttribution: travist commentedSimple mistake...
Comment #77
joachim CreditAttribution: joachim commentedSorry, but this still isn't working at all :(
Preview gets me this AJAX error:
Fatal error: Cannot access empty property in /Users/joachim/Sites/module-lab/sites/all/modules/contrib/webform/views/webform_handler_field_data.inc on line 196
And when my next operation in the admin page shows this:
warning: Invalid argument supplied for foreach() in /Users/joachim/Sites/module-lab/sites/all/modules/contrib/webform/views/webform_handler_field_data.inc on line 130.
I have a webform with a text and a select component, and I simply create a 'webform submissions' view and add your field -- that's it.
Comment #78
travist CreditAttribution: travist commentedThis is because the webform you are trying to show has no components, which I didn't test that use case. Here is a new patch that will handle this, but you will need to set the Webform ID within the field settings so that it knows which webform to base the component fields after.
I am also currently working on making an exposed filter so that the user can actually select which webform they would like to see, and will probably contribute the patch for that when I am done, but for now, you can just use the field settings to hard code that webform ID...
Hope this one works better...
Thanks for testing...
Travis.
Comment #79
joachim CreditAttribution: joachim commented> I am also currently working on making an exposed filter so that the user can actually select which webform they would like to see
I think in most cases you'd want a non-exposed filter -- imagine you're making an admin list of webform submissions, you'd make it for one particular webform. Though an argument too might be useful.
Comment #80
roball CreditAttribution: roball commentedjoachim, did the last patch finally work for you?
Comment #81
travist CreditAttribution: travist commentedI ran into a snag where the clone was causing some issues. This next patch is much better since it does not handle the field globally but rather each instance is atomic in how it handles its data and how it is rendered.
Please give this one a shot.
Thanks,
Travis.
Comment #82
travist CreditAttribution: travist commentedJust realized that get_class can be used to get the class name. This patch fixes that.
Comment #83
travist CreditAttribution: travist commentedOne minor change. Found that the previous patch falls into infinite loop if the first component is a fieldset.
Comment #84
travist CreditAttribution: travist commentedShould be the last one. Need to check to make sure that the alias exists before rendering.
Comment #85
travist CreditAttribution: travist commented10th time is the charm right? ;)
Comment #86
Anonymous (not verified) CreditAttribution: Anonymous commentedCan we have it on D7 ?
Best regards
ArchGalileu
Comment #87
roball CreditAttribution: roball commentedCan the last patch please be tested by someone on D6 first?
Comment #88
Anonymous (not verified) CreditAttribution: Anonymous commentedHi roball
I tested the D6 patch and it shows the data from, can't choose fields but is good.
should be nice to have arguments to present in different submissions
Best regards
ArchGalileu
Comment #89
roball CreditAttribution: roball commentedGood to know the patch from travist seems to work just fine, as a first direction. Would be great to reach RTBTC status once.
Comment #90
travist CreditAttribution: travist commentedArchGalileu,
I think the best approach to pulling in different webforms would be to build an exposed filter to show all the webforms and then have that populate the webform used to pull in the data. I am slated to work on this next sprint, so I will either include that in this issue, or submit a new issue to include that patch.
Unfortunately, we are still on D6 at the moment, but upgrading the patch to D7 should not be too difficult since the API between views on D6 and D7 is near identical. In fact, I would be curious if the patch above works for D7 as is, but that is something I have not tested.
Thanks,
Travis.
Comment #91
travist CreditAttribution: travist commentedHere is a new patch with a very minor change from the previous. I included a new function to check to make sure that we are only including webform components that are input types... this way we are not building a view of data from components such as markup or pagebreaks.
Comment #92
Anonymous (not verified) CreditAttribution: Anonymous commentedHi travist
It gives error: it says "handler broken or missing" for the webform submission data
Waiting instructions
Best regards
ArchGalileu
Comment #93
brant CreditAttribution: brant commentedsubscribe
Comment #94
maurop1982 CreditAttribution: maurop1982 commentedsubscribe and interested in D7 patch
Comment #95
bigjim CreditAttribution: bigjim commentedI was able to get it to work, though it's pretty limited without sort/argument/filter handlers. I'm gonna kick the tires and see if I can write something.
@ArchGalileu you may need to clear the views cache
Comment #96
travist CreditAttribution: travist commentedA new update to this patch. Nothing major... just a minor bug fix to keep all webform submissions from coming in if there is no webform ID provided.
Comment #97
travist CreditAttribution: travist commentedAfter more testing, I realized that we need to filter based on the node ID of the webform, and also unset the webform_submission table if there is no webform available. This next patch realizes that.
Comment #98
travist CreditAttribution: travist commentedMore regression testing realized that support for "multiple" fields was broken where it would only show the first multiple value. This updated patch fixes it so that it shows all the values when "multiple" is selected.
Comment #99
lsolesen CreditAttribution: lsolesen commented+1
Comment #100
Jorrit CreditAttribution: Jorrit commentedI get the following error:
PHP Fatal error: Call to undefined method stdClass::join() in /var/www/www.travelhome.nl/drupal/sites/all/modules/views/plugins/views_plugin_query_default.inc on line 1018
I use Views 3 alpha 4 on Drupal 6. I suspect the patch is made for Views 2?
Comment #101
travist CreditAttribution: travist commentedThe patch is against Views 3. But I think I know what is causing your issue... Does your webform have any components added to it? If not, then you may get this error. I will submit a new patch soon that will not add the SID field if there are no components.
Comment #102
Jorrit CreditAttribution: Jorrit commentedThe sid did point to a node with components. I have already tried other solutions, so I can't give you the view code that gave the error. With your patch, do views need to be created on the Node table or on the Webform submissions table? Maybe I did something wrong there.
Comment #103
travist CreditAttribution: travist commentedEither one should work. If you start with a node table view, you can just use relationships to bring in the webform_submissions table. Did you configure your field to include the Webform NID? This setting is in the field.
Comment #104
Jorrit CreditAttribution: Jorrit commentedYes, I recall that I did that.
Comment #105
Marko B CreditAttribution: Marko B commentedHope this gets into official relase soon. Also in my opinion every major module should have views integration and should be made to support it, that is if we want to build something that is compatible and when combined offers lots of power.
Comment #106
quicksketchThe current patch travist put together looks like a good start. I like that it's simple from the user-perpsective, but such "automatic" joins are generally frowned upon these days. In Views 3, even the automatic relationship to the Node Author has been removed. I'd feel better about this arrangement if the relationship were responsible for the joining (and specifying which NID was going to be used), and if it provided support beyond simple display fields (such as filtering, sorting, etc.)
It's definitely better than nothing, but I'm not sure the current approach is suitable for Webform core.
Comment #107
ccoppen CreditAttribution: ccoppen commentedIs this work being done just on 6.x-3.x-x or will any of it work with 7?
I would like to use a charts module with this, but unfortunately, there's no easy solution, nor has there been for 7.
Comment #108
quicksketchThe API is mostly compatible between Views 3 for D7 and Views 2/3 for D6. It should work across versions.
Comment #109
derhasi CreditAttribution: derhasi commentedWe are currently working on a Drupal Views Code Sprint here in Hamburg and are about to post a patch to this issue soon. We are working on a solution quicksketch proposed in comment-106, using Views Relationships to join the data via views relationships. Hope to post a patch tonight.
Comment #110
derhasi CreditAttribution: derhasi commentedOk, the patch is not there yet, but I want to share the "fork" with you, for the work we allready did: https://github.com/derhasi/webform/tree/issue680386_views_submission_data
@quicksketch, you could push to the repo, if you want to ;)
Comment #111
Murzderhasi, does https://github.com/derhasi/webform/tree/issue680386_views_submission_data contains already patch for views integration or not?
Comment #112
derhasi CreditAttribution: derhasi commentedMurz, it does, but it's not final. It very likely will change in some parts and so differs from a potential webform release.
Comment #113
brammer CreditAttribution: brammer commentedsubscribe
Comment #114
MurzI have created new feature request for convert webform_submitted_data to Drupal 7.x entities: #1360244: Convert webform submissions to Drupal 7.x entities
I think this way will much better than working with current webform_submitted_data table.
Comment #115
quicksketchThanks @derhasi, this approach looks promising. I just reviewed the branch diffs to get an idea of the implementation and it looks good so far. It's right inline with my thinking. However both that branch and the patch @travist has put together aren't ready for inclusion yet. Regarding @travist's approach, see my comment in #106.
Comment #116
derhasi CreditAttribution: derhasi commentedI'll try to finish a releasable patch within this week ;)
Comment #117
derhasi CreditAttribution: derhasi commentedSo, there I finally got a patch that introduces:
Not implemented (yet): multi value display and component type specific filters/arguments.
The patch is tested in D7 (not in D6 - but I added the views handler definition, so it could work there too).
Comment #118
cangeceiro CreditAttribution: cangeceiro commentedI am trying the patch in #117. when going to a view and try to add a relationship i get the following "The Handler For This Item Is Broken Or Missing And Cannot Be Used. If A Module Provided The Handler And Was Disabled, Re-Enabling The Module May Restore It. Otherwise, You Should Probably Delete This Item." running 3.15
Comment #119
leoklein CreditAttribution: leoklein commentedsubscribing
Comment #120
timb CreditAttribution: timb commentedsubscribing
Comment #121
derhasi CreditAttribution: derhasi commentedleoklein, timb, could you test the patch in #117 ?
Comment #122
dhz CreditAttribution: dhz commentedI've just installed this patch and it works. Thanks a lot !
Do you have an idea when this patch will be included in the webform module ?
Comment #123
derhasi CreditAttribution: derhasi commentedcangeceiro, did you test with the latest dev?
Comment #124
derhasi CreditAttribution: derhasi commentedComment #125
BeatnikDude CreditAttribution: BeatnikDude commentedThere is not currently a 7.x-3.x-dev available for testing?
I tested the patch on the 7.x-3.x-dev I had available. (datestamp = "1324429105", from the .info file)
In this case the patch fails for me:
Comment #126
derhasi CreditAttribution: derhasi commentedBeatnikDude, due to the prefix
a/
andb/
created bygit diff
, you need to apply the patch usingpatch -p1 < webform_views_submitted_data-680386-117.patch
.Attached is a new patch that freshly applies to the current
7.x-3.x
-branch (only some line numbers changed to #117).Comment #127
BeatnikDude CreditAttribution: BeatnikDude commentedThanks for the heads up, not yet hip to the git, and thanks for the patch.
I applied the patch @#126 to Webform 7.x-3.15.
Works for me, I was able to:
Comment #128
timb CreditAttribution: timb commentedafter reading the instructions on patching in #126, i was able to get this running for me also. thx
Comment #129
jrao CreditAttribution: jrao commentedIf I choose Webform submission data: Data field (formatted) as field, the following error appears when view is displayed:
Notice: Undefined index: #parents in theme_webform_element() (line 2613 of drupal\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2613 of drupal\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2613 of drupal\sites\all\modules\webform\webform.module).
Notice: Undefined index: field_prefix in _webform_display_textfield() (line 173 of drupal\sites\all\modules\webform\components\textfield.inc).
Notice: Undefined index: field_suffix in _webform_display_textfield() (line 174 of drupal\sites\all\modules\webform\components\textfield.inc).
Notice: Undefined index: #parents in theme_webform_element() (line 2613 of drupal\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2613 of drupal\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2613 of drupal\sites\all\modules\webform\webform.module).
Using (raw) avoids this problem.
Two other issues:
1. If I try to add a Feed, I got error "Style RSS Feed requires a row style but the row plugin is invalid"
2. If I use http://drupal.org/project/views_datasource I can get json/xml output which is very impressive, but the fields are named data, data_1, etc, not convenient for integration with other systems.
Comment #130
manoloka CreditAttribution: manoloka commentedwill this work for D6?
Comment #131
derhasi CreditAttribution: derhasi commented@manoloka, it may work but maybe needs some more work. First this patch should be applied to D7.
@jrao, what component type did you use?
Your other "two issues" are "issues" of the display plugins.
Comment #132
manoloka CreditAttribution: manoloka commentedThanks, please let us know once is ready to be ported to D6 ... great work (as usual)
Comment #133
quicksketchWebform maintains a policy of feature-parity between both D6 and D7 while within the same version number (currently 3.x). So before this can be applied to D7, it needs a patch for D6 also.
Comment #134
roball CreditAttribution: roball commentedThus, derhasi would you like to port your D7 patch to D6?
Comment #135
rschwab CreditAttribution: rschwab commentedAttached is patch 126 plus support for date modules nice calendar popups and date select lists.
Edit: Well thats odd, I don't know why my patch is significantly smaller than #126. All I did was clone, apply, add the few lines to check for date module and then add its handler if present, then git diff'd. The first few lines in the patch are what counts.
Comment #136
quicksketchThanks for the reroll. git diff doesn't include new files unfortunately, which is why your patch is so much smaller.
Comment #137
travist CreditAttribution: travist commentedrschwab,
First stage all of your files using
git add [PATH TO FILE]
Then stage your changes to the code using
git add -p
Once everything is staged, you can then type the following within the webform folder to get the complete diff.
git diff --staged --relative > webform_views_submitted_date-680386-136.patch
Comment #138
rschwab CreditAttribution: rschwab commentedThanks travist! I'm still quite the git noob. This patch looks a lot closer to correct.
Comment #139
nodecode CreditAttribution: nodecode commentedCan't wait to test! You folks working on this issue are about to alter Webform in a VERY positive and dramatic way! So awesome.
Comment #140
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedwill i be able to use this with views charts or views customfield modules with webform to be able to build reports baed on webform submissions?
Comment #141
thebuckst0p CreditAttribution: thebuckst0p commentedI have a client interested in this functionality, so I'm testing out the patch in #138.
One bug I notice - the relationship forms don't remember the selected fields. #default_value in the select elements probably needs to be set/changed.
Comment #142
thebuckst0p CreditAttribution: thebuckst0p commentedAlso seeing this warning --
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2523 of webroot/sites/all/modules/webform/webform.module).
I fixed the issue I mention in #141, I'll try to fix this one too, and submit a modified patch.
Comment #143
thebuckst0p CreditAttribution: thebuckst0p commentedModified patch from 138, for issues described in 141 and 142.
My solution to 142 suppresses the warnings but might not be the best approach, someone with more knowledge of webform elements should review it.
The patch style is different, using git on a site repo rather than the module's repo, but it should apply the same way.
Thank you for this patch!
Comment #144
xl-network CreditAttribution: xl-network commentedCool it works! I'm subscribing to receive updates.
Comment #145
tim.plunkettTrailing whitespace, the comment needs a period, the if needs a space after it, and the curly brace should only have one space before it.
This comment is duplicated.
Since webform has it's own date component, that is not a date.module field, no other modules integrating with Views will detect it as a date. It doesn't seem that this will be possible, since the data isn't stored per component.
Comment #147
rennevat CreditAttribution: rennevat commentedThank you! Using this patch http://drupal.org/node/680386#comment-5555750 as well as http://drupal.org/node/1435846, resulted in being able to create a views node reference to return Webform submission data (filtered on node id) of the results within a selected data component, as well as add the view to a content field via Node Reference.
Works as needed with the exception of the Node Reference key=>value. What is being returned in the select list is nid=>data. But all the results of the component are from the same node id (due to node filtering in view). Is it possible to have data=>data returned (so that the selected data for the node matches the webform data, ie. orgId=>orgId) or to select two components from the Webform and use one as the key and the other as the label (orgId=>orgName)?
Comment #148
laroccadahouse CreditAttribution: laroccadahouse commentedthis is exactly what i've been needing! thank you for your work on this. Is there any work being done to use the formatted value of the data in filters and sorts instead of the raw value?
Comment #149
wizonesolutionsThe patch in its current form mostly worked for me, but I had to manually fix one line...a 1 was changed to use
$nested_level
. There are other issues I can't correct in the previous patch right now, so just leaving this note.Comment #150
conniemh CreditAttribution: conniemh commentedHi everyone,
First, thank you all for your hard work on this functionality. With some tedium in adding the relationship per field the patch works for me on smaller forms. Unfortunately my current task is creating some very large forms with over 60 fields, so I may have to find some alternatives to views for returning some data on some of the sites web pages.
We do not use Drush here, so I implemented the latest patch (http://drupal.org/node/680386#comment-5555750) by hand.
Line 388 - 400 of the patch:
In the latest posted version of 7.x-3.x-dev, the function theme_webform_element($variables) starts on line 2644 rather than 2520. And as wizonesolutions noted, there is a completely different statement for the $parents string on line 2644:
Replacing this with the single line
seems to cause no problems or errors, but I was wondering if I was using the wrong version of the patch or the dev module since the line numbers and contents did not match. I am no programmer, so I could just be missing something obvious here. Bottom line is that it works, so maybe the patch is just a little out of date....but just wanted to be sure I was not missing something.
Thanks again for this patch,
Connie
Comment #151
wizonesolutionsconniemh: As mentioned in my comment, the patch is out of date. I would have remade it when I was testing it, but I didn't have enough insight as to how to fix the actual problems it had, so I didn't (and it was late).
If a programmer is handling the implementation and you were planning to go the custom route, I'd recommend contributing back to this issue. Patching Webform and then eventually dropping the patch when this is committed would probably take just as long as cooking up something custom for scratch - especially for Webform submission data.
My two cents.
Comment #152
flightrisk CreditAttribution: flightrisk commentedI'm a little lost as to what the status on this is. Is this rolled into a release yet? My need is for "Internal only" views support, so this is only for admin types. I don't have to worry about performance because users are not going to run views reports.
I have a submission form for "support". I have private fields for Action1/Date1/Comment1, Action2/Date2/Comment2, etc. When someone submits a support webform, I want to be able to track what is done until it is "resolved". So I need Views to create custom pages/reports. I want this:
Doe, John
Address
Phone
Issue
-------------------------------
Action1: spoke on phone, Date1: 11/11/12, Comment1: told him I would call back tomorrow
Action2: sent new driver, Date2: 11/27/12, Comment2: wait to hear back
Action3: resolved, Date3: 11/30/12, Comment3: reported back that it works
Comment #153
quicksketchNo, if it were this issue would be marked "fixed" or "closed (fixed)".
Comment #154
flightrisk CreditAttribution: flightrisk commentedOk, thank you. I guess that means it is still a manual patch and not in a dev release? Is the intent for this addition to be able to create the kind of report I mentioned? I saw one message that said only text fields are supported. I'm wondering if this will expose all of the fields in a form to views. This is great work, BTW. I am trying to learn what you've done and see how the database works since you mentioned the way the table is setup, views is a difficult addition.
If you add views support and if privacy by role or other access control is supported (my next thing to check) there is virtually nothing you couldn't do with user submissions and admin tracking of those submissions. The "private" setting for fields works for the fist part of what I'm trying to do (allow only admins to see fields related to tracking what's been done with the submission), but I need a user to be able to see the status of their own submission while not being able to see others' submissions. Right now, "status" is a private field. Is there a way to have a "read only" field? I want admins to make a dropdown selection for "accepted/rejected" or "open/closed", but have the user only be able to view it, not change it.
Comment #155
BenK CreditAttribution: BenK commentedJust skimmed through this thread.... so is the patch in comment #143 the current patch to be testing? Does this patch need to be re-rolled for the latest 7.x-3.x-dev?
Comment #156
tim.plunkettYes, but see the comments in #145.
Comment #157
flightrisk CreditAttribution: flightrisk commentedArgh, this is so frustrating. Why is in not a normal date field as is used in every other module? I guess I am missing something important in the design of this module. Drupal 7 has all the standard fields already there, I use date fields everywhere. Why create the same kind of fields unique just to this module? I have about 50 modules I am using and this is the first time I've run into this. Is it because all the other modules work on content types, nodes and entities?
Comment #158
tim.plunkettYes. Also, check the created date on the Webform module as compared to the CCK module (the predecessor of the D7 Field UI), and Date module:
Date: June 26, 2006 at 9:17pm
CCK: February 7, 2006 at 7:35pm
Webform: April 26, 2004 at 4:54pm
Comment #159
flightrisk CreditAttribution: flightrisk commentedAhhh! Now we are getting somewhere! Thanks Tim, I had no idea. Now I see from whence the issues arise ;) I'll keep plugging away at it.
Comment #160
DrupalDan CreditAttribution: DrupalDan commentedHi guys,
I was suggested to use #143 patch so that I can use views to show specific webform submission. Patching remains a little mysterious to me and when I trying to do the patching using Git Bash, I got the message "fatal: git diff header lacks filename information when removing 1 leading pathname components". Can anyone please tell me what that means or how to proceed with patching this module?
Many thanks!
Comment #161
fenstrat@DrupalDan see http://drupal.org/patch/apply
Comment #162
DrupalDan CreditAttribution: DrupalDan commentedHi fenstrat, thanks for your response. I read that page but still I don’t know where I went wrong. So I will describe my steps as follow, hopefully it can make the problem exposed.
1. I used Git Bash and I navigate to c:/wamp/www/sites/all/modules
2. I copied and entered the command from webfom vision control: git clone --recursive --branch 7.x-3.x http://git.drupal.org/project/webform.git.
And then I got the message “fatal: destination path ’webform’ already exists and is not an empty directory”. I figured that means I need to remove the module from there and I just did that. Then I can do the clone, which was successful.
3. I put the patch file into all/modules/webform folder and I entered cd webform
4. I entered the command “git apply –v webform_views_submitted_data-680386-143.patch” and that’s where I got the message “fatal: git diff header lacks filename information when removing 1 leading pathname components”.
I did that a couple of times but the result was the same. I’m completely lost and I can really use some help. Thanks!
Comment #163
fenstratThis is an untested reroll of #143 and addresses the review in #145.
I've also removed
+ $parents = is_array($element['#parents']) ? str_replace('_', '-', implode('--', array_slice($element['#parents'], 1))) : '';
.@DrupalDan the patch in #143 was made to apply with the old -p0 format hence your troubles apply with
git apply
. This one here will apply withgit apply
.Comment #164
fenstratSame patch at #163 just fixes new lines at end of files.
Comment #165
DrupalDan CreditAttribution: DrupalDan commentedThank you very much fenstrat! It's so good to know the cause of it finally! I just tried the 164 one and it apply cleanly.
I've been trying to figure out what change it brings. I don't know if this is relevant to this issue but in views I only found the following 5 options:
Webform: Status
Webform: Webform edit link
Webform: Webform form body
Webform: Webform results link
Webform: Webform submission count
Just for clarification, I'm seeking a way to make the data of one specific submission shown directly, each field one by one (name, email address, image, etc.), so that I can make it as a view attached to a node. But it seems that the above 5 options are irrelevant to this purpose. Can you tell me how to do this?
Thanks again!
Comment #166
fenstrat@DrupalDan you need to create a new Relationship of type "Webform submissions: Data" for each webform field you want to use in your view. This can be a lot of relationships if you've got many fields but it was done for architectual reasons. Please read the comments above for more info.
Comment #167
DrupalDan CreditAttribution: DrupalDan commented@fenstrat I tried to add a new Relationship of type “Webform submission: Data” and what’s strange is that I saw no such option there as the screenshot.
Also, I’ve trying to follow along the steps described as #127 but when I tried to add a View showing Webform submissions, I saw no such an option under FIELDS or FILTER CRITERIA. Screenshots are attached, too.
I apologize if I ignore anything and cause this. Thanks!
Comment #168
nmc CreditAttribution: nmc commentedTested patch in #164 and still having some issues. Only the first selected options are showing up the in results. Each option is rendered as a record/line which is exactly what I'm looking for but the data (selected option field) is missing for anything other than the first option.
I am also getting this error:
Strict warning: Declaration of webform_handler_field_submission_data::pre_render() should be compatible with that of views_handler_field::pre_render() in require_once() (line 13 of ..../modules/webform/views/webform_handler_field_submission_data.inc).
Comment #169
fenstratAttached fixes the strict warning mentioned in #168, which is due to views now expeciting the param by reference, i.e.
pre_render(&$values)
notpre_render($values)
.Re multivalue fields, this patch is still largly the work of @derhasi in #117 which as he states there:
If you look through the patch you'll see there's a number of @todo's
@DrupalDan Sounds like you've not cleared your caches. Try that, then the new options should show up in views.
Comment #170
DrupalDan CreditAttribution: DrupalDan commented@fenstrat, I patched the 169 and cleared the caches but still, the options are not there. Is patching 169 the only change I should make and the options will show up? I just want to make sure I didn't miss anything.
Thanks!
Comment #171
fenstrat@DrupalDan yeah if you apply #169 to 7.x-3.x-dev and clear caches the new options should show up in views. Make sure you're using Webform submissions as the base table for the view - i.e. at admin/structure/views/add select Show: Webform submissions.
Comment #172
DrupalDan CreditAttribution: DrupalDan commented@ fenstrat, thank you, thank you very much for your message! That’s exactly what I didn’t do; I’m new to drupal and it is till now that I realize what “base table” actually is, but I might never be able to figure the whole things out on my own.
I got one more question, is it possible to display the image uploaded in Views rather than the file’s destination path? I’ve been trying to use the webform to receive author’s content submission and display everything submitted, including his/her photo. It’s like a profile page but profile modules are not really what I’m looking for.
Thanks again for your help!
Comment #173
DrupalDan CreditAttribution: DrupalDan commentedNotice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of
I'm not sure if it's the right place to report this. Sorry if it's not.
The bug occurs when I attach the view showing webform submission as a child view of another view using the module "Views Field View", but I'm not sure if that's the real cause.
C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of C:\wamp\www\sites\all\modules\webform\webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of C:\wamp\www\sites\all\modules\webform\webform.module).
Comment #174
quicksketch@DrupalDan, until this patch is committed to the project, the issue should stay as a "feature request". If it's not ready to be committed to the project (say you run into a bug after applying the patch like this), move the Status of the issue to "needs work".
Comment #175
DrupalDan CreditAttribution: DrupalDan commentedSorry for that. I'll make sure I get the status right when having an issue. Thanks.
Comment #176
calbert CreditAttribution: calbert commentedHow do I apply this patch, what the command.
Comment #177
quicksketchhttp://drupal.org/patch/apply
Comment #178
calbert CreditAttribution: calbert commentedI applied this patch and I still don't see my forms in views ( as I did in 6.x ) or any fields from my form.
Am I doing something wrong?
Comment #179
BeatnikDude CreditAttribution: BeatnikDude commented@calbert use the process at #127 to create a view using Webform submissions.
I will test the latest patch, I would love to see this committed.
Comment #180
quicksketchThanks guys, the more testing the better. I'd like feedback not only on "if it works" but also on how well it works and how easy it is to understand. Better views support would enable all kinds of great functionality.
@calbert was nice enough to move this to the 4.x branch, which is where this functionality will ultimately be added. By targeting 4.x, we won't be backporting this to Drupal 6.
Comment #181
DrupalDan CreditAttribution: DrupalDan commentedI think it’s very easy to use for someone even like me, a drupal novice, as it calls for nothing particular but an understanding of Views and of some very basic concept (base table for example). I don’t know if this is a good idea, but perhaps it would be better if it can have something to do with files, like having some options people can choose how that info is displayed, file path destination or the file itself for view or download, maybe? I’m not a programmer and I know only very little about PHP, so hopefully that’s not a stupid idea to share.
Comment #182
quicksketchProviding access to uploaded files would also be a good idea, though that Views implementation might be tricky as well. Because Webform stores all its submitted data in a "text" column, you can't easily JOIN it to other tables (such as the "managed_files" table, which stores things like the file name and size). In order to make such relationships/JOINs possible, we'd need an integer-based column as suggested in #1057252: Webform and private files is not indexable on MySQL, broken elsewhere.
It's good feedback but let's punt more advanced File handling to a follow up issue. It's currently our only data that is stored in another table that would require deeper integration.
Comment #183
BeatnikDude CreditAttribution: BeatnikDude commentedUsing: Webform 7.x-4.0-alpha1
Applied Patch: #164 (how-to)
Process to access WebForm data in a View:
Note:
~Thanks
Comment #184
calbert CreditAttribution: calbert commentedI get an error on step two
add a Relationship "Webform submissions: Data
"The handler for this item is broken or missing and cannot be used. If a module provided the handler and was disabled, re-enabling the module may restore it. Otherwise, you should probably delete this item."
Comment #185
nmc CreditAttribution: nmc commentedPatch in #169 got rid of the errors I was seeing, but options still aren't rendering correctly. Only the first option chosen is displayed. The remaining chosen options render the correct line/entry but the data in the Options column is missing.
Comment #186
kclarkson CreditAttribution: kclarkson commentedThis is great stuff.
We will be using this feature for faculty award applications. This feature will allow us to list submitted applications on each person's profile without having to make each application its own content type.
Hooorayyy webforms
thanks for the hard work.
Comment #187
BeatnikDude CreditAttribution: BeatnikDude commented@calbert, I went back and verified that this process worked for me: add a Relationship > Webform submissions > Webform submissions: Data > Component type > Component. Select a Component type and Component from an existing webform.
@nmc, my options are working. You are using the "Multiple" option in an Option select component, correct? I have not tried that.
Comment #188
nmc CreditAttribution: nmc commented@BeatnikDude: yes, I'm using the "Multiple" option in an Option select component. What have you used for yours that is currently working?
Comment #189
BeatnikDude CreditAttribution: BeatnikDude commented@nmc: I am using Form components (w/ & w/o the Listbox option).
I can verify that Option select components w/ the "Multiple" option selected fail to display properly. As per screenshots comparing webform results table rendering and my current test webform view.
Looks like the pre_render() function at line 184 in the #164 patch is where this need to be dealt w/?
// @TODO: maybe we add a multi value pre query here?
I also see the attempt to deal w/ this in the patch #98.
Comment #190
calbert CreditAttribution: calbert commented@BeatnikDude
When I look at your views I see what I am looking for, maybe your running a different version of views/webform?
I am running views 7.x-3.3
Webform 7.x-4.0-alpha1 ( just switch to this alpha)
I have screenshots of what happens maybe this will help?
Comment #191
calbert CreditAttribution: calbert commentedI just did a clean slate of everything and I noticed in the patch that hunk 1 failed at 14
Here is the code from webform.info.rej
***************
*** 14,22 ****
files[] = views/webform_handler_field_node_link_results.inc
files[] = views/webform_handler_field_submission_count.inc
files[] = views/webform_handler_field_submission_link.inc
files[] = views/webform_handler_field_webform_status.inc
files[] = views/webform_handler_filter_is_draft.inc
files[] = views/webform_handler_filter_webform_status.inc
files[] = views/webform.views.inc
files[] = tests/components.test
--- 14,24 ----
files[] = views/webform_handler_field_node_link_results.inc
files[] = views/webform_handler_field_submission_count.inc
files[] = views/webform_handler_field_submission_link.inc
+ files[] = views/webform_handler_field_submission_data.inc
files[] = views/webform_handler_field_webform_status.inc
files[] = views/webform_handler_filter_is_draft.inc
files[] = views/webform_handler_filter_webform_status.inc
+ files[] = views/webform_handler_relationship_submission_data.inc
files[] = views/webform.views.inc
files[] = tests/components.test
Comment #192
BeatnikDude CreditAttribution: BeatnikDude commented@nmc, I am running:
• Views 7.x-3.3
• Webform 7.x-4.0-alpha1
• I don't seem to have any failure on the patch, I used:
patch -p1 < path/file.patch
vs.
git apply path/file.patch
• attached is my version of your 1 and 2.
Comment #193
calbert CreditAttribution: calbert commentedOK maybe I am doing something wrong with the patch
I saved # 169 as 680386-169-webform_views_submissions_data.patch
Then uploaded it to my modules/webform directory
Then ran the command
patch -p1 < 680386-169-webform_views_submissions_data.patch
and I get that hunk 1 failed at 14
Comment #194
calbert CreditAttribution: calbert commentedOK I nuked the webform directory and started from scratch and I can now add a Relationship "Webform submissions: Data
When I do however, it doesn't show up in fields .. for example
Component type *
Select component type for this relationship
Components: Number
Webform 4: Ticket Number (ticket_number)
I go into Fields and Webform ticket number is no listed.
Comment #195
BeatnikDude CreditAttribution: BeatnikDude commentedadd the Field "Webform submission Data" for each Relation you create.
Comment #196
calbert CreditAttribution: calbert commentedOk, so here's my update fresh install, and now the patch works.
I add a Webform submission Data for each Relationship field I need.
When I save and view the page I get the following error block
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: array_slice() expects parameter 1 to be array, null given in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Warning: implode() [function.implode]: Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/vhosts/metrosource/drupal-7/sites/all/modules/webform/webform.module).
Comment #197
davemac326 CreditAttribution: davemac326 commentedGood Tutorial on how to use Webform MySQL Views + Data / Schema to tie out webform submission data to views. It's based off of Drupal 6 but it still applies to 7. It works well enough but always take care for backing up frequently.
One note about the video - in D7 - the views will appear after you adopt the tables and create the joins. That's how it worked for me.
http://dev.nodeone.se/node/666
The "666" is purely coincidental.
Comment #198
ycwjjjj CreditAttribution: ycwjjjj commentedsubscribe
Comment #199
ycwjjjj CreditAttribution: ycwjjjj commentedApplied patch from #164 in Drupal 7 with webform, data, schema and entity module installed.
Thanks!
Comment #200
DrupalDan CreditAttribution: DrupalDan commentedError
Hi I've been importing and exporting my db to the web. When that process is done, I got this message in my server's phpmyadmin. Can anyone knows how to fix this?
SQL query: Documentation
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `webform_views_contributing_user_profile_form_258` AS select `parent`.`sid` AS `sid`,`s`.`uid` AS `uid`,(select group_concat(`child`.`data` separator ',') from `webform_submitted_data` `child` where ((`child`.`sid` = `parent`.`sid`) and (`child`.`cid` = 1))) AS `full_name`,(select group_concat(`child`.`data` separator ',') from `webform_submitted_data` `child` where ((`child`.`sid` = `parent`.`sid`) and (`child`.`cid` = 2))) AS `email_address`,(select group_concat(`child`.`data` separator ',') from `webform_submitted_data` `child` where ((`child`.`sid` = `parent`.`sid`) and (`child`.`cid` = 3))) AS `department`,(select group_concat(`child`.`data` separator ',') from `webform_submitted_data` `child` where ((`child`.`sid` = `parent`.`sid`) and (`child`.`cid` = 6))) AS `institution`,(select group_concat(`child`.`data` separator ',') from `webform_submitted_data` `child` where ((`child`.`sid` = `parent`.`sid`[...]
MySQL said: Documentation
#1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation
Comment #201
neurovation.kiwi CreditAttribution: neurovation.kiwi commentedwell, this is quite off topix and you probably can do a google search, but here is the resolution, nevertheless:
just go into your dumped file, and either remove the line where the "definer" is set, or change the user "root" to the user you really use.
Comment #202
vishusrinivasan CreditAttribution: vishusrinivasan commentedHi all, can this function be supported as a separate module. I have tested the module in http://drupal.org/node/1219954#comment-5078056 and it works fine, I was able to add the fields and filters in views using this module. But there are some issues with it as discussed in http://drupal.org/node/1219954#comment-6194386 .
Your comments please.
Comment #203
allenshorter CreditAttribution: allenshorter commentedI second that!!! Really could use this functionality in the next couple of weeks as either a separate module, or part of the webforms module.
Comment #204
BeatnikDude CreditAttribution: BeatnikDude commentedI am currently using this module patched, as per #183. I would love to see Views integration committed to the Webform module.
~Thanks to quicksketch and all.
Comment #205
ydahiWebform: 7.x-4.0-alpha1
Patch from #164
(all as outlined by BeatnikDude on #189)
--EDIT-- This problem was also "solved" by changing the identifiers. Works well, so please disregard below. --EDIT--
First, I don't get the clean names - the only fields available to me as called Datafield (formatted), Datafield (raw), and Datafield (delta). [check screenshots 1 and 2]
--EDIT-- I was able to remove the issue below by using (raw) instead of (formatted) --EDIT--
Secondly, the table display is workable, however I get an error message when viewing the output but not in the preview [screenshot 3]:
Any help would be greatly appreciated. Thanks for you efforts in this useful module.
Comment #206
drewish CreditAttribution: drewish commentedI've been looking at the patch in comment #169 and I'm not sure I understand why the relationship allows multiple components. Especially since selecting multiple components gives a row for each component. I don't see the motivation for that. It also makes it much more complicated if you wanted to do something like export a table of selected values you have to add a relationship for each component, name it in such a way that you know which is which, then add a field for each. Why not just have the logic be in the field handler so instead you just add multiple copies of the field handler and select the component from there?
Comment #207
drewish CreditAttribution: drewish commentedSo one bug in the patch on #169 the field handler options form doesn't show the "display format" because the variable is named wrong:
It should be $form['format']. And that #required needs to be moved too.
I'm also not sure why the webform_handler_field_submission_data class has a $component_type property since it's never used.
webform_handler_relationship_submission_data::get_webform_component_instances() seems to do extra work:
could be simply:
and
could be:
Personally I'd prefer filtering out 'pagebreak' and 'hidden' components.
That said I've been working on field handler that handles the work the relationship handler is doing right now. Pluses to the relationship include sorting, filtering, etc but I think there's something to be said for having a simpler way to be able to view the component values, in my case I need to build a few views with 10+ components on each so the relationship starts to seem like a PITA.
Comment #208
drewish CreditAttribution: drewish commentedHere's a patch that fixes the issues I'd pointed out. I'm going to spend some time reworking the relationship handler to only use a single component at a time but I wanted to post a clean version incase people don't like my direction.
Comment #209
drewish CreditAttribution: drewish commentedOkay this one is a bit more radical. After reading back through the old posts I get why the option to select multiple components is useful so I'm preserving that. I'm doing relationship per field so I tried to optimize that case a bit and avoid the CONCAT() in the query. I think I simplified the relationship handler and got rid of a bunch of helper functions in the process.
We've got 1300 components so I was running into the max_input_vars limit that was added in PHP 5.3.9 which was killing off part of the form. So it might make sense to go back to quicksketch's original approach of having separate instances per component type.
Comment #210
drewish CreditAttribution: drewish commentedOh I should note that in all versions of this patch when you use the formatted field handler there's a bunch of notices being generated about:
PHP Notice: Undefined index: #webform_component in /Users/amorton/Sites/dosomething/sites/all/modules/webform/components/select.inc on line 546
I'm not sure what the right fix for that is. I tried switching from webform_component_instances()'s results to webform_menu_component_load() but it didn't seem to matter. I'm guessing that the components are expecting that _webform_client_form_add_component() was called on them and it's not.
Comment #211
quicksketchThanks @drewish for your work in improving this patch! I'm overall still very unsure about this new approach, so I'm thrilled to see it put into action in a scenario where you have a large number of components. This would certainly be a great feature to include but I want to get it right, since it's extremely difficult to "take back" Views integrations after they've been out in the wild since views regularly get exported to code and built into other modules (both contrib and custom).
I just fixed this in #1462986: Undefined index: #webform_component in select.inc. I made a new alpha5 release you can use to remedy that problem.
Comment #212
quicksketchUgh, well apparently I haven't looked at this patch in a while. Apparently since @derhasi's patch in #117 when this whole thing went down a rabbit hole that couldn't possibly be used.
This approach of loading every possible component from every webform node is unacceptable. We can't assume a limited number of Webform components. There are plenty of sites out there that have 10,000+ Webforms and 100,000s of components. This approach doesn't scale. Sigh. I thought this was getting somewhere while I was leaving it alone but it looks like it needs quite a bit of work.
Comment #213
drewish CreditAttribution: drewish commentedYeah I wondered about that. It seeme nasty but I'd assumed it was "approved". Is there a suggested way to query/load components or should I just run queries?
Comment #214
quicksketchYeah apparently leaving a patch alone for 9 months can let it run down a rabbit hole of rerolls that don't lead anywhere. :P
I rerolled this patch so that it scales by limiting each relationship to a single node. So you first select the node (via autocomplete), then choose the fields explicitly from that node instead of every node in the system.
I still don't know if this is the right direction to go... it seems rather unnatural.
Multiple values still seem like they're a problem in this iteration of the patch. If you have a multi-value field (such as checkboxes) then you end up with one row per value. I think this could be fixed by an approach where we don't JOIN when adding a field. Instead we can imitate the Field module integration where the entire node is loaded to pull out field values. We can do the same thing with submissions and load the entire submission when displaying fields and only require JOINs/relationships when filtering/sorting. It'd probably result in more efficient (speed-wise, not memory-wise) approach overall.
@drewish you said you understood why selecting multiple fields was valuable, I can't figure out what purpose it serves, seems like you could/should add two relationships if you want to select two fields, since otherwise you end up with multiple rows (one for each component selected) per submission. It seems like you'd want at most one row per submission.
Comment #215
quicksketchOh, here's the rerolled version. Still needs work but at least functions to the level of the previous patches.
Comment #216
quicksketchHere's a heavily revised patch that I think is significantly easier and more natural to use. If some of the reviewers here would give it a shot, I think it's something we can pursue.
It's generally based on @derhasi's #117 and @drewish's most recent reroll but with some significant changes:
- Based on #214, it scales to any number of nodes. This solution would work fine with 100,000+ webform nodes.
- Each relationship or field only may select a single component from a single node. I think this approach is less error-prone than the multi-component feature, for which I couldn't figure out a purpose anyway. You can still get multiple components by using multiple relationships.
- To improve the display of values and to solve the display of multi-value components (such as checkboxes) or components that need additional loading (such as files), I've changed the *field* handler to load the entire submission and then pull out the needed. All submissions for the current page are loaded in one query and cached so no matter how many fields you add it doesn't add complexity to the main SQL query (which only selects the submission ID). This can turn out to be quite a bit faster in a lot of situations since it uses fully indexed columns instead of JOINs.
- You no longer need to add a relationship to select webform submitted values in the field handler (since it uses the new loading method I just described). Instead you select the node and component you want to display directly in the field handler configuration.
- You do still need to add a relationship for filtering/sorting, since this is a requirement of any SQL query that is going to use an ORDER BY or WHERE clause.
- You can still add a "raw" value by adding a relationship first, which can be used to provide a click-sortable table column. This approach also doesn't load the entire submission if you'd prefer to use 1 or 2 JOINs instead of loading the submissions (though data formatting options aren't as good).
Things that aren't so hot but could probably be added later:
- Exposed filters and sorts are all string-based textfields. This includes things that don't work well with textfields like date, time, and select components.
- Speaking of date and time components, an obvious feature would be to filter before/after a particular date/time. This isn't supported either yet in our string-based implementation.
I think both of these problems can be fixed by adding a dedicated filter/sort handlers for the "Raw" data version instead of using the Views default string based one, but this approach already seems to fit 80%+, I'd be fine with adding those later. Patch applies to latest 7.x-4.x branch.
Comment #217
rudiedirkx CreditAttribution: rudiedirkx commentedI've solved this problem quite differently. It's nastier technically, but more efficient. It uses Views fields and then overwrites them via query alter. Like I said: nastier. The resulting query would then be something like:
and no other queries are necessary during post execute or render. (The
{node}
join is added by Webform because I added a nid filter. It's not necessarily necessary.)As you can see (or not) the data from virtual table
wf6c3
is a multivalue field (no
isn't checked and delta/no is fetched too). The module combines those multi fields inviews_post_execute
.It's probably unrelated, because it's a completely different approach, but I just wanted to share.
Sandbox: http://drupal.org/sandbox/rudiedirkx/1783098
Comment #218
quicksketchThanks @rudiedirkx. I checked out your module and though it has the same scaling problem (loading every Webform node on the site and then adding its information into hook_views_data() could be catastrophic for some sites), the approach is interesting. I'm not 100% sure it's significantly more performant than the current approach. Two SQL queries with no JOINs can be faster than one SQL query with several JOINs. Yhough webform_get_submissions() also includes two JOINs so in your example it's probably more efficient, in situations with a large number of fields the "load the whole submission" would overtake the multiple-join approach.
In any case if you used the "Raw value" fields/relationships you can accomplish the same thing in the existing patch if it was more appropriate for your situation. What we need in the core Webform project is something that works across the board and in any scaled situation (whether that's lots of components, columns of data, or webform nodes). I think we may have that with the current approach.
Comment #219
quicksketchThis patch adds greater than and less than options to the filters so that you can filter before/after dates. The interface still isn't great (it would ideal to have the Webform rendering of date/time elements when displayed as exposed filters), but it's at least capable of getting the right results when used by administrators.
This patch also fixes a SQL error with the field handler when no results are matched.
Comment #220
quicksketchI've committed this iteration of the patch which is the same as #219 except I cut the Date module integration on the "submitted" database column. It was causing PHP errors for me because it apparently has coded dependencies on Field API and the Date field structure, rather than being something that can be applied to an arbitrary column like the webform_submissions.submitted column.
Please try out the Webform 7.x-4.0-alpha6 version for further testing this feature, and open new issues for any feature requests or bugs.
Comment #221
yannickooSo cool, thanks quicksketch! *party*
Comment #222
drewish CreditAttribution: drewish commentedQuicksketch, I realized I'd never explained what I though the win of multiple components on one relationship was. My understanding was it helped in the case where you had two webforms that both had say a date component so you could put them both into the same column on a view. Since each node would only have a single matching cid both nodes would get the value and would only result in a single row.
Comment #223
rudiedirkx CreditAttribution: rudiedirkx commentedYes, fetching fields over different webforms is very awkward like this. I have 3 webforms: 2 with a Name component and 1 with a First name and Last name. There's no way I can make one View with all submissions' Names. (With my solution it is, but I understand your hesitation.)
And also like this you can't use the webform component's types... I think a webform component should map to a views field. Not 1 views field for all components in all webforms.
Maybe a solution is to force all machine names to be of the same type (like Field does) and then add those as Views fields (like Field does). This way there's little hook_views_data overhead and you can use webform_submission_load (or joins) and you can use the components' types. It might break/corrupt a lot of webforms though, but that's why it's a major release IMO.
For me it's important to be able to combine webforms. With commit 7a6c37d it's not.
Comment #224
BeatnikDude CreditAttribution: BeatnikDude commentedLet's not make "the Perfect the Enemy of the Good". Is it worth holding up the ability to use simple Webform Views till it handles mixing Webforms in views or handling 100k+ components?
My uses are not so demanding but nonetheless would greatly benefit from this functionality.
I will test the latest patch ASAP.
~thanks
Comment #225
quicksketchYou can still combine Webform's however you'll need a JOIN for each separate Webform node. Considering there's no guarantee that the CIDs will line up between different nodes (and there's no way you can change them), I don't think that's something that can be easily depended upon.
That's potentially an option. We've already got "field_key" though, and for a lot of forms it's important to allow non-unique forms (say when cloning an "address" group of fieldsets, you would want field keys maintained inside the fieldset).
As I've said above a couple times, we can't load all the components for all nodes into the Views data. It would would completely overwhelm the system on a site that had a large number of Webforms (which is not uncommon).
I mentioned doing one-field-per-component-*type* above. That's what #18 even does so that each field type can have a separate handler. However I found the approach confusing from an end-user perspective. I think that if we use the same mechanism of AJAX-loading the form after a component has been selected in the Views field configuration, I think we'll be able to overcome most limitations of one field approach. Considering all fields are text columns, all stored in the same table, and all behaving the same way, I don't think we'll need a huge level of customization. Ideally, we'll be able to reuse the existing form-building functions we already have for exposed filters, making the filters behave like the component would within a form.
Comment #227
pianomansam CreditAttribution: pianomansam commentedI didn't know if I should create a separate issue, but when attempting to upgrade to 7.x-4.0-alpha6 from 7.x-3.18 specifically to use this feature, I get "Broken/missing handler" for when attempting to add a Webform submissions: Data relationship. Is there anything else I need to have in place? Any dev versions of other modules?
Comment #228
dmenefee CreditAttribution: dmenefee commentedHas this been back-ported to D6? I have a site on that version of Drupal that would really benefit from this update. thanks!
Comment #229
fenstrat@dmenefee The 3.x branch of webform, both for Drupal 6 and 7, is not receiving any new features. So no, this won't be back ported.
Comment #230
MilOrg CreditAttribution: MilOrg commentedI've created a fairly large form that will be used as a template for forms submitted from subdomains. The way the views integration works now, relationships has to be created for each of the fields. When creating a new form based on the template, the old view won't work unless the relationships are changed on each and every field to point to the new nid.
Just wanted to check if this is the way the views integration most likely will work once implemented in a release version, or if there are changes on the roadmap rendering this little obstacle obsolete?
Comment #231
c4rl CreditAttribution: c4rl commentedI needed this for Drupal 6. I know this issue is closed, but here's a patch I did for D6 that probably isn't perfect. In retrospect, some of the techniques are similar to what is done in #220, though it didn't influence the work here. Be warned: some of the sub-queries may be malperformant. :)
Nevertheless, give it a shot if it seems useful to you. Also see http://archive.org/details/DisplayWebformSubmissionDataInViews for a different technique.
Comment #232
hovel CreditAttribution: hovel commentedHi c4rl, This is just what i need for Drupal 6. Unfortunately it does not seem to work and i have verry limited time to check i out.
I get an error:
In the views preview.
Comment #233
SpokjeFor the (unfortunate) people out there who are stuck on 7.x-3.x, here's a reroll of the patch in #220 against the latest 7.x-3.x.
Note: The only difference is the removal of the "Call-time pass-by-reference" in line 81 of
views/webform_handler_filter_submission_data.inc
:Original #220 patch:
which is now:
Call-time pass-by-reference has been removed in PHP 5.4