Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi!
We are developing our second webform extension module, which is not currently public, because it will be a part of a bigger package. While developing 'webform2pdf', we were thinking about, that it would be useful to put our own operations into the 'Operation' column of the webform submission page. We managed to find a workaround, but that solution wasn't perfect.
We can't avoid doing that in our new module though. I don't think it is a good idea to insert a supported module into webform core module sources (see print module related modification at http://api.lullabot.com/theme_webform_results_submissions).
I'd be glad to make a patch for it, if you help me, where to put the code, and which hook should I use.
Thanks in advance!
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | webform_results_table6_fix.patch | 844 bytes | quicksketch |
| #8 | webform_results_table6.patch | 10.23 KB | quicksketch |
| #8 | webform_results_table7.patch | 10.23 KB | quicksketch |
| #4 | webform-893090-1.patch | 9.14 KB | mr.york |
Comments
Comment #1
quicksketchI think this would be a great idea. The most common way is to have the options for edit/delete/print/view/etc. as actual elements in the form with #type == 'markup'. Then we can print out any operations for each item directly in the theme function. So basically move the logic from the theme function into the building of the form instead.
Comment #2
mr.york commentedI'm sorry if the question wasn't clear enough, but I think we aren't talking about the same thing, as AFAIK there isn't any form at "?q=node/NID/webform-results". Do you think we should convert this page into a form, or are you talking about a webform node page?
Comment #3
quicksketchOh dear, you're quite correct. I don't know what I was thinking. Perhaps we can build this out as a renderable (a la Drupal 7), which is essentially the same thing as a form and put in our own alter hook to change it. So essentially we build it as a form and then render it as a form in the theme function. Considering this is the way Drupal 7 works with just about everything, it could be a good way to get Webform more in-line with Drupal 7's approaches anyway. Of course we'd make this change in the 6 version too.
Comment #4
mr.york commentedPatch:
Comment #5
mr.york commentedComment #6
quicksketchThanks, this patch looks like a great start. Isn't a drupal_alter() call necessary in order for other modules to add their own actions?
Comment #7
mr.york commentedI don't use drupal_alter() because template_preprocess_webform_results_submissions() can be implemented in a module, and the changes can be made there.
Comment #8
quicksketchWorks for me. I've committed your patch with a few minor changes. If you're using this patch in production, the most important change here is that I've used $table['#rows'] instead of $table['rows'], for better compatibility with Drupal 7. So in webform-results-submissions.tpl.php we have the following:
D6:
D7:
Other than that, changes are just cosmetic. Attached are the committed versions for D6 and D7. Thanks for the patch!
Comment #9
mr.york commentedThank you!
Comment #10
mr.york commentedSorry :).
Comment #11
quicksketchI found a bug in the D6 version that would cause all submission listings to show as empty. This patch fixes that one problem (caused by my changing 'rows' into '#rows').