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.

Files: 
CommentFileSizeAuthor
#231 webform-680386-231.patch15.17 KBc4rl
#220 webform_views_submitted_data.patch21.49 KBquicksketch
#219 webform_views_submitted_data.patch21.71 KBquicksketch
#216 webform_views_submitted_data.patch17.16 KBquicksketch
#215 webform_views_submitted_data.patch12.11 KBquicksketch
#209 webform_680386.patch12.99 KBdrewish
#208 webform_680386.patch13.92 KBdrewish
#205 webform-sshot1.PNG35.34 KBydahi
#205 webform-sshot2.PNG21.19 KBydahi
#205 webform-sshot3.PNG49.23 KBydahi
#192 1_Add-relationship_Webform-submission-data.png26.18 KBBeatnikDude
#192 2_Configure-Relationship_Webform-submissions_Data.png55.43 KBBeatnikDude
#190 webform1.jpg77.47 KBcalbert
#190 webform2.jpg107.42 KBcalbert
#190 webform3.jpg93.6 KBcalbert
#190 webform4.jpg92.87 KBcalbert
#189 direct-_from-webform-results-table.png17.9 KBBeatnikDude
#189 webform_view_multiselect_fields.png17.2 KBBeatnikDude
#187 view.png116.94 KBBeatnikDude
#187 view.edit_.png110.53 KBBeatnikDude
#185 Clipboard01.jpg21.59 KBnmc
#169 680386-169-webform_views_submissions_data.patch13.24 KBfenstrat
#167 screenshot-relationships.png31.81 KBDrupalDan
#167 screenshot-fields.png35.87 KBDrupalDan
#167 screenshot-filter.png33.13 KBDrupalDan
#164 680386-164-webform_views_submissions_data.patch13.24 KBfenstrat
#163 680386-163-webform_views_submissions_data.patch13.26 KBfenstrat
#143 webform_views_submitted_data-680386-143.patch13.67 KBthebuckst0p
#138 webform_views_submitted_data-680386-138.patch13.13 KBrschwab
#135 webform_views_submitted_date-680386-135.patch5.07 KBrschwab
#126 webform_views_submitted_data-680386-126.patch12.75 KBderhasi
#117 webform_views_submitted_data-680386-117.patch12.75 KBderhasi
#98 680386-views-webform_submissions_data-98.patch9.42 KBtravist
#97 680386-views-webform_submissions_data-97.patch8.52 KBtravist
#96 680386-views-webform_submissions_data-96.patch7.99 KBtravist
#91 680386-views-webform_submissions_data-91.patch7.97 KBtravist
#85 680386-views-webform_submissions_data-85.patch7.45 KBtravist
#84 680386-views-webform_submissions_data-84.patch7.39 KBtravist
#83 680386-views-webform_submissions_data-83.patch7.29 KBtravist
#82 680386-views-webform_submissions_data-82.patch7.27 KBtravist
#81 680386-views-webform_submissions_data-81.patch7.39 KBtravist
#78 680386-views-webform_submissions_data-78.patch7.7 KBtravist
#76 680386-views-webform_submissions_data-76.patch7.15 KBtravist
#73 680386-views-webform_submissions_data-73.patch7.46 KBtravist
#68 680386-views-webform_submissions_data-68.patch5.73 KBtravist
#18 webform_submitted_data_view.patch8.33 KBquicksketch
#5 Screenshot.png13.71 KBDgrey

Comments

From 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... :)

Unlike 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.

Oh 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).

An 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.

StatusFileSize
new13.71 KB

I 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.

Subscribing, greetings, Martijn

Dgrey,

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?

Version:» 6.x-2.9

Subscribing..

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.

Subscribing.

Version:6.x-2.9» 6.x-3.x-dev

Sub.

Issue tags:+views, +webform

Subscribing 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...

Subscribe. 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.

The 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.

Sudden 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.

subscribing

(totally-not-a)subscribe...

StatusFileSize
new8.33 KB

Here'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.

I 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...

While 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.

Can I subscribe to this bug somehow, so I am notified of new developments?

OK quicksketch I just tried your patch. Awesome! Thank you.
I had no issues with it in my tests. Good work.

subscribing

Version:6.x-3.x-dev» 6.x-3.0-beta5

subscribing

subscribing

I 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

Version:6.x-3.0-beta5» 6.x-3.0-beta6
Status:Active» Needs work

The 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.

It 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.

@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.

I am able to get the patch to work when i take out all the components that are not textfield or textarea.

subscribing

QuickSketch,

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

Nevermind - I see how you can access your own submissions without using views. Thanks!

subscribing

subscribing

@ #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.

Subscribe

Version:6.x-3.0-beta6» 6.x-3.x-dev

Anyone 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.

subscribe

Status:Needs work» Needs review

I 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.

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.

This 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.

I 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

select ws.nid, ws.sid, wsd.cid, wsd.no, wsd.data
from webform_submissions ws
left join webform_submitted_data wsd on ws.sid = wsd.sid
where ws.nid = %

There's probably a couple dozen reasons why this is still either infeasible, unrecommended or insane.

subscribe

subscribe

subscribe

subscribe

Take a look at:
http://nodeone.se/blogg/finally-webform-submission-data-in-views
He uses the webform_mysql_views and data modules.

Status:Needs review» Needs work

Putting this back into needs work, clearly our current patch isn't yet viable since it only works for textfields.

Subscribing

subscribe

subscribe

Drupal 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*

subscribing and agreeing with the above post.

Following the screencast provided in #47 i was able to get the webform-data in views. Thank you!

subscribing

subscribe

I'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.

+1

Webform 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.

Great screencast. Thanks for posting that servantleader.

subscribe

Subscribing

subscribing

sub

subscribing

Subscribing.

Here 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.

Status:Needs work» Needs review

Subscribing

Subscribing

Status:Needs review» Needs work

the 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:

    warning: Invalid argument supplied for foreach() in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/webform/views/webform_handler_field_data.inc on line 99.
    warning: Invalid argument supplied for foreach() in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/views-DRUPAL-6--3/plugins/views_plugin_query_default.inc on line 895.
    warning: Invalid argument supplied for foreach() in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/views-DRUPAL-6--3/plugins/views_plugin_query_default.inc on line 971.
    warning: Invalid argument supplied for foreach() in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/views-DRUPAL-6--3/plugins/views_plugin_query_default.inc on line 895.
    user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM webform_submissions webform_submissions ) count_alias' at line 2 query: SELECT COUNT(*) FROM (SELECT FROM webform_submissions webform_submissions ) count_alias in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/views-DRUPAL-6--3/plugins/views_plugin_pager.inc on line 141.
    user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM webform_submissions webform_submissions LIMIT 0, 10' at line 2 query: SELECT FROM webform_submissions webform_submissions LIMIT 0, 10 in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/views-DRUPAL-6--3/plugins/views_plugin_query_default.inc on line 1108.

If I do specify a nid, I get the same errors AND the preview button says:

An error occurred at /module-lab-drupal-6/admin/build/views/ajax/preview/webform_patch.
Error Description:
( ! ) Fatal error: Cannot access empty property in /Users/joachim/Sites/module-lab-drupal-6/sites/all/modules/webform/views/webform_handler_field_data.inc on line 151

So, 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...

Status:Needs work» Needs review

Why do you change

-    'help' => t('Submissions generated from Webform forms.'),
+    'help' => t('Submissions grenerated from Webform forms.'),

?

Simple mistake...

Status:Needs review» Needs work

Sorry, 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.

This 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.

> 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.

Status:Needs work» Needs review

joachim, did the last patch finally work for you?

I 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.

Just realized that get_class can be used to get the class name. This patch fixes that.

One minor change. Found that the previous patch falls into infinite loop if the first component is a fieldset.

Should be the last one. Need to check to make sure that the alias exists before rendering.

10th time is the charm right? ;)

Can we have it on D7 ?

Best regards
ArchGalileu

Can the last patch please be tested by someone on D6 first?

Hi 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

Good to know the patch from travist seems to work just fine, as a first direction. Would be great to reach RTBTC status once.

ArchGalileu,

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.

Here 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.

Hi travist

It gives error: it says "handler broken or missing" for the webform submission data

Waiting instructions

Best regards
ArchGalileu

subscribe

subscribe and interested in D7 patch

I 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

A 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.

After 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.

More 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.

+1

I 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?

The 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.

The 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.

Either 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.

Yes, I recall that I did that.

Hope 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.

Hope 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.

The 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.

Is 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.

The API is mostly compatible between Views 3 for D7 and Views 2/3 for D6. It should work across versions.

Issue tags:+dvcs11

We 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.

Ok, 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 ;)

derhasi, does https://github.com/derhasi/webform/tree/issue680386_views_submission_data contains already patch for views integration or not?

Murz, it does, but it's not final. It very likely will change in some parts and so differs from a potential webform release.

Version:6.x-3.x-dev» 7.x-3.9

subscribe

I 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.

Status:Needs review» Needs work

Thanks @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.

I'll try to finish a releasable patch within this week ;)

Version:7.x-3.9» 7.x-3.x-dev
Status:Needs work» Needs review
StatusFileSize
new12.75 KB

So, there I finally got a patch that introduces:

  • Relationship to the submission data table by component type (and component instance) selection
  • Field for formatted output via component's display hook.
  • field, filter, sort and argument for raw value
  • field, filter, sort and argument for delta (numeric)

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).

Status:Needs review» Needs work

I 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

subscribing

subscribing

leoklein, timb, could you test the patch in #117 ?

I'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 ?

cangeceiro, did you test with the latest dev?

Status:Needs work» Needs review

There 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:

# patch < webform_views_submitted_data-680386-117.patch
patching file webform.views.inc
Hunk #1 FAILED at 140.
Hunk #2 FAILED at 233.
Hunk #3 FAILED at 255.
3 out of 3 hunks FAILED -- saving rejects to file webform.views.inc.rej
patching file webform_handler_field_submission_data.inc
patching file webform_handler_relationship_submission_data.inc
patching file webform.info
patching file webform.module
Hunk #1 succeeded at 3415 (offset 150 lines).

BeatnikDude, due to the prefix a/ and b/ created by git diff, you need to apply the patch using patch -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).

Version:7.x-3.x-dev» 7.x-3.15
Status:Needs review» Reviewed & tested by the community

Thanks 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:

  1. add a View showing Webform submissions, then in that view
  2. add a Relationship "Webform submissions: Data" (I tried email, fieldset, select options, text area, & textfield), then
  3. I can add the Field "Submission Data" and choose the relationship I created, and/or
  4. I can add the Filter criteria "Submission Data" and choose the relationship I created

after reading the instructions on patching in #126, i was able to get this running for me also. thx

If 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.

Version:7.x-3.15» 6.x-3.15

will this work for D6?

Version:6.x-3.15» 7.x-3.x-dev

@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.

Thanks, please let us know once is ready to be ported to D6 ... great work (as usual)

@manoloka, it may work but maybe needs some more work. First this patch should be applied to D7.

Webform 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.

Status:Reviewed & tested by the community» Patch (to be ported)

Thus, derhasi would you like to port your D7 patch to D6?

Attached 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.

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.

Thanks for the reroll. git diff doesn't include new files unfortunately, which is why your patch is so much smaller.

rschwab,

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

Thanks travist! I'm still quite the git noob. This patch looks a lot closer to correct.

Can't wait to test! You folks working on this issue are about to alter Webform in a VERY positive and dramatic way! So awesome.

will 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?

I 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.

Also 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.

Modified 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!

Cool it works! I'm subscribing to receive updates.

Status:Patch (to be ported)» Needs work

+++ views/webform.views.incundefined
@@ -92,6 +92,11 @@ function webform_views_data() {
+  ¶
+  // Add date module support, if present
+    if(module_exists('date')) {
+      $data['webform_submissions']['submitted']['filter']['handler'] = 'date_views_filter_handler_simple';

Trailing whitespace, the comment needs a period, the if needs a space after it, and the curly brace should only have one space before it.

+++ views/webform.views.incundefined
@@ -140,6 +145,68 @@ function webform_views_data() {
+  // For each component type, we implement a custom field.

+++ views/webform.views.incundefined
@@ -140,6 +145,68 @@ function webform_views_data() {
+  // For each component type, we implement a custom field.

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.

Thank 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)?

this 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?

The 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.

Hi 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:

diff --git webform.module webform.module
index 15f704b..ff4b7fd 100644
--- webform.module
+++ webform.module
@@ -2520,7 +2520,7 @@ function theme_webform_element($variables) {
   else {
     $type = (isset($element['#type']) && !in_array($element['#type'], array('markup', 'textfield'))) ? $element['#type'] : $element['#webform_component']['type'];
   }
-  $parents = str_replace('_', '-', implode('--', array_slice($element['#parents'], 1)));
+  $parents = is_array($element['#parents']) ? str_replace('_', '-', implode('--', array_slice($element['#parents'], 1))) : '';
   $wrapper_classes = array(
    'form-item',

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:

// Convert the parents array into a string, excluding the "submitted" wrapper.
     $nested_level = $element['#parents'][0] == 'submitted' ? 1 : 0;
     $parents = str_replace('_', '-', implode('--', array_slice($element['#parents'], $nested_level)));

Replacing this with the single line
$parents = is_array($element['#parents']) ? str_replace('_', '-', implode('--', array_slice($element['#parents'], 1))) : '';

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

conniemh: 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.

I'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

Is this rolled into a release yet?

No, if it were this issue would be marked "fixed" or "closed (fixed)".

Ok, 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.

Just 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?

Yes, but see the comments in #145.

Argh, 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?

Is it because all the other modules work on content types, nodes and entities?

Yes. 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

Ahhh! 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.

Hi 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!

Hi 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!

Status:Needs work» Needs review
StatusFileSize
new13.26 KB

This 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 with git apply.

Same patch at #163 just fixes new lines at end of files.

Thank 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!

@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.

StatusFileSize
new33.13 KB
new35.87 KB
new31.81 KB

@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!

Tested 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).

Attached fixes the strict warning mentioned in #168, which is due to views now expeciting the param by reference, i.e. pre_render(&$values) not pre_render($values).

Re multivalue fields, this patch is still largly the work of @derhasi in #117 which as he states there:

Not implemented (yet): multi value display and component type specific filters/arguments.

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.

@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!

@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.

@ 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!

Category:feature» bug
Status:Needs review» Active

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
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).

Category:bug» feature
Status:Active» Needs work

@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".

Sorry for that. I'll make sure I get the status right when having an issue. Thanks.

Status:Needs work» Needs review

How do I apply this patch, what the command.

Version:7.x-3.x-dev» 7.x-4.0-alpha1

I 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?

@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.

Thanks 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.

I 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.

Providing 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.

Using: Webform 7.x-4.0-alpha1
Applied Patch: #164 (how-to)

Process to access WebForm data in a View:

  1. add a View showing Webform submissions. then in that view…
  2. add a Relationship "Webform submissions: Data", select the Webform Component you want to use. (I created Relationships for email, select options, text area & textfield.) then…
  3. add the Field "Webform submission Data" for each Relation you created and choose the relationship you created. and/or...
  4. add the Filter criteria "Webform submission Data" and choose the relationship you created. and/or...
  5. add a Sort criteria sort "Webform submission Data" and choose the relationship you created. Table sorting works as well.

Note:

  • Views usage is not intuitive, I hope the above helps people.
  • For every Webform element I want to view as a Field I created a Relationship.
  • Create Administrative titles for Relations and Fields in your View to save your sanity.

~Thanks

I 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."

StatusFileSize
new21.59 KB

Patch 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.

Webform Submission View with missing Options

This 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.

StatusFileSize
new110.53 KB
new116.94 KB

@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.

@BeatnikDude: yes, I'm using the "Multiple" option in an Option select component. What have you used for yours that is currently working?

@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.

StatusFileSize
new92.87 KB
new93.6 KB
new107.42 KB
new77.47 KB

@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?

I 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

@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.

OK 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

OK 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.

add the Field "Webform submission Data" for each Relation you create.

Ok, 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).

Good 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.

Applied patch from #164 in Drupal 7 with webform, data, schema and entity module installed.
Thanks!

Error

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

well, 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.

Hi 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.

I second that!!! Really could use this functionality in the next couple of weeks as either a separate module, or part of the webforms module.

I 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.

StatusFileSize
new49.23 KB
new21.19 KB
new35.34 KB

Webform: 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]:

Notice: Undefined index: field_prefix in _webform_display_textfield() (line 180 of /var/www/drupal/sites/all/modules/webform/components/textfield.inc).
Notice: Undefined index: field_suffix in _webform_display_textfield() (line 181 of /var/www/drupal/sites/all/modules/webform/components/textfield.inc).
Notice: Undefined index: #parents in theme_webform_element() (line 2694 of /var/www/drupal/sites/all/modules/webform/webform.module).
Notice: Undefined index: #parents in theme_webform_element() (line 2695 of /var/www/drupal/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/drupal/sites/all/modules/webform/webform.module).
Warning: implode(): Invalid arguments passed in theme_webform_element() (line 2695 of /var/www/drupal/sites/all/modules/webform/webform.module).

Any help would be greatly appreciated. Thanks for you efforts in this useful module.

I'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?

So one bug in the patch on #169 the field handler options form doesn't show the "display format" because the variable is named wrong:

+    // Provide the selection for the display format.
+    $options['format'] = array(
+      '#type' => 'select',
+      '#title' => t('Display format'),
+      '#options' => array(
+        'html' => 'html',
+        'plain' => 'plain',
+        '#required' => TRUE,
+      ),
+      '#default_value' => $this->options['format'],
+    );

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:

+      $components = webform_component_instances();
+      foreach ($components as $key => $component) {
+        $this->component_instances[$key] = $component;
+      }

could be simply:

+      $this->component_instances = webform_component_instances();

and

+    foreach ($this->component_instances as $data) {
+      if (!isset($component_type) || $data['type'] == $component_type) {
+        // Component primary key is (nid, cid).
+        $components["{$data['nid']}-{$data['cid']}"] = check_plain("Webform {$data['nid']}: {$data['name']} ({$data['form_key']})");
+      }
+    }

could be:

+    foreach ($this->component_instances as $key => $data) {
+      if (!isset($component_type) || $data['type'] == $component_type) {
+        $components[$key] = check_plain("Webform {$data['nid']}: {$data['name']} ({$data['form_key']})");
+      }
+    }

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.

StatusFileSize
new13.92 KB

Here'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.

StatusFileSize
new12.99 KB

Okay 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.

Oh 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.

Thanks @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).

Oh 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 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.

Status:Needs review» Needs work

Ugh, 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.

+function webform_component_instances() {
+  $instances = &drupal_static(__FUNCTION__);
+
+  // Build the static.
+  if (!isset($instances)) {
+    $query = db_select('webform_component', 'wc')
+              ->fields('wc')
+              ->execute();
+    while ($assoc = $query->fetchAssoc()) {
+      $key = "{$assoc['nid']}-{$assoc['cid']}";
+      $assoc['extra'] = unserialize($assoc['extra']);
+      $instances[$key] = $assoc;
+    }
+  }
+  return $instances;
+}

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.

Yeah 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?

Yeah 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.

StatusFileSize
new12.11 KB

Oh, here's the rerolled version. Still needs work but at least functions to the level of the previous patches.

Version:7.x-4.0-alpha1» 7.x-4.0-alpha5
Status:Needs work» Needs review
StatusFileSize
new17.16 KB

Here'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.

I'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:

SELECT webform_submissions.sid AS sid, wf6c1.data AS webform_submissions_wf_6_first_name, wf6c2.data AS webform_submissions_wf_6_last_name, wf6c3.data AS webform_submissions_wf_6_function, wf6c3.no AS webform_submissions_wf_6_function__delta
FROM
{webform_submissions} webform_submissions
LEFT JOIN {node} node ON webform_submissions.nid = node.nid
LEFT JOIN {webform_submitted_data} wf6c1 ON webform_submissions.sid = wf6c1.sid AND (wf6c1.cid = '1' AND wf6c1.nid = '6' AND wf6c1.no = '0')
LEFT JOIN {webform_submitted_data} wf6c2 ON webform_submissions.sid = wf6c2.sid AND (wf6c2.cid = '2' AND wf6c2.nid = '6' AND wf6c2.no = '0')
LEFT JOIN {webform_submitted_data} wf6c3 ON webform_submissions.sid = wf6c3.sid AND (wf6c3.cid = '3' AND wf6c3.nid = '6')
WHERE (( (node.nid = '6') ))

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 in views_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

Thanks @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.

StatusFileSize
new21.71 KB

- 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.

This 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.

Status:Needs review» Fixed
StatusFileSize
new21.49 KB

I'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.

So cool, thanks quicksketch! *party*

Quicksketch, 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.

Yes, 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.

Let'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

For me it's important to be able to combine webforms. With commit 7a6c37d it's not.

You 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.

Maybe a solution is to force all machine names to be of the same type (like Field does)

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).

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.

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.

Status:Fixed» Closed (fixed)

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

I 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?

Version:7.x-4.0-alpha5» 6.x-3.9
Status:Closed (fixed)» Active

Has this been back-ported to D6? I have a site on that version of Drupal that would really benefit from this update. thanks!

Version:6.x-3.9» 7.x-4.0-alpha5
Status:Active» Closed (fixed)

@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.

I'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?

StatusFileSize
new15.17 KB

I 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.

Issue tags:-views, -webform

Hi 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:

warning: implode() [function.implode]: Invalid arguments passed in C:\UniServer\www\toneelfonds\sites\all\modules\webform\views\webform_handler_field_component.inc on line 42.

In the views preview.