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!

Comments

quicksketch’s picture

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

mr.york’s picture

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

quicksketch’s picture

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

mr.york’s picture

FileSize
9.14 KB

Patch:

mr.york’s picture

Status: Active » Needs review
quicksketch’s picture

Thanks, this patch looks like a great start. Isn't a drupal_alter() call necessary in order for other modules to add their own actions?

mr.york’s picture

I don't use drupal_alter() because template_preprocess_webform_results_submissions() can be implemented in a module, and the changes can be made there.

quicksketch’s picture

Status: Needs review » Fixed
FileSize
10.23 KB
10.23 KB

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

  <?php print theme('table', $table['#header'], $table['#rows']); ?>

D7:

  <?php print render($table); ?>

Other than that, changes are just cosmetic. Attached are the committed versions for D6 and D7. Thanks for the patch!

mr.york’s picture

Status: Fixed » Needs review

Thank you!

mr.york’s picture

Status: Needs review » Fixed

Sorry :).

quicksketch’s picture

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

Status: Fixed » Closed (fixed)

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