I needed to be able to print submissions in a simple format--something much more compact than the form that gets rendered, or something at least suitable for copying and pasting into a word processing program.

I have hacked together a small patch to allow this. If there is sufficient interest, I could perhaps clean it up a bit. My forms are fairly simple, so I'm not sure it will work very well for all the different component types.

CommentFileSizeAuthor
#16 webform_display_rendering.patch89.78 KBquicksketch
#1 webform-5.x-1.7_printable.patch2.32 KBHorsePunchKid
webform-5.x-1.4_printable.patch2.27 KBHorsePunchKid
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

HorsePunchKid’s picture

HorsePunchKid CreditAttribution: HorsePunchKid commented
FileSize
webform-5.x-1.7_printable.patch2.32 KB

Rerolled for the 1.7 release, in case anyone is interested.

Rowanw’s picture

Rowanw CreditAttribution: Rowanw commented

What about using a print stylesheet? Works for me.

holydrupal’s picture

holydrupal CreditAttribution: holydrupal commented

It wont work for version 5.2
any idea how we could print a simple webform by print-friendly module?

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

I'd also like to get a printable feature into Webform. It's always been a bit strange that Webform re-uses the existing form to actually display data. Rather than making another case in each component, I think we should replace the _webform_submission_display function in each component (and make it a theme function). We might even be able to reuse the theme_webform_mail() function within each component to also output text within the browser. Just an idea. I mostly just wanted to say that improving the display of results has my support and I'd be all-for committing changes.

holydrupal’s picture

holydrupal CreditAttribution: holydrupal commented

I am currently print my webform results by adding print in a webform url:

http://www.yoursite.com/print/node/node-ID/submission/submission-NO

Although the appearance of the print is ugly, because it prints all the fields boxes. but at this time it is the only solution I found.

canen’s picture

canen CreditAttribution: canen commented

Any update on this?

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented

Tracking.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Version: 5.x-1.x-dev » 5.x-2.x-dev

I used the 1.7 patch above as a model and was able to get the same functionality for version 2.x of the module. I'll try to clean up my code and roll a patch against the current version.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

xjm, the existing patch needs a tremendous amount of work. As I mentioned above, we need to make a theme function for each component and make the final printable output run through theme() functions also. I'd be thrilled to make these changes, but there'd be no way I could commit a port of the existing patch.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented

Well, in that case, I'll just keep my little hack for now, as I don't really need the printable version to be themable (though it would be nice). Hopefully someone else with the time to drupal-ify the functionality has an interest in this, because it would round out the module.

grey_’s picture

grey_ CreditAttribution: grey_ commented

xjm #10 You don't happen to have that little hack available? I would very much like to see it :)

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented

Alright: YMMV, raw data, use with caution, etc. Perhaps someone putting together a theming API for webform printing can use this to get started.

Also, looking at the code below, I think $user in the callback arguments is going to be the current user rather than the user who submitted the node, so perhaps that would need to be fixed.

Add a menu item in hook_menu:

        $items[] = array(
          'path' => 'node/'. $nid .'/submission/'. $sid .'/print',
          'title' => t('Print'),
          'callback' => '_webform_submission_print',
          'callback arguments' => array($node, $submission,$user),
          'access' => webform_submission_access($node, $submission, 'view'),
          'weight' => 1,
          'type' => MENU_LOCAL_TASK,
        );

The above might be different in Drupal 6 (which has different menu handling).

And the callback, which ATM is only dependent on the webform module; not sure if the 6.x version is compatible or not:

function _webform_submission_print($node, $submission,$user) {
  $output = "<html><head>";
  $output .=<<<STYLE
    <style type="text/css">
  div.webform-meta { font-style: italic; margin-bottom: 1em; }
  div.webform-component { margin-bottom: 1em; }
  label { font-weight: bold; }
  h1 { font-size: 140%; }
  h2 { font-size: 120%; border-bottom: solid 1px #000; margin-top: 2em; }
  </style>
STYLE;
  $output .= "</head><body>\n";
  $output .= "<h1>Form Submission: " . $node->title . "</h1>\n";
  $output .= "<div class='webform-print'>\n";
  $output .= "<div class='webform-meta'>";
  $output .= "Submitted: ".date("r", $submission->submitted)
    . " by " . theme_username($user)
;

  $output .= " (Submission ID ".$submission->sid . ")";
  $output .= "</div>\n";

  foreach ($node->webform['components'] as $cid => $component) {
    switch ($component['type']) {
    case "fieldset":
      $output .= "<h2>" . $component['name'] . "</h2>\n";
      break;
    case "date":
      $output .= "<div class='webform-component'>\n";
      $output .= "<label>" . $component['name'] . ":</label>\n";
      if ($submission->data[$cid]['value'][0]) {
        $output .= "<span class='webform-value'>".implode($submission->data[$cid]['value'],"/")."</span>\n";
      }
      $output .= "</div>\n";
      break;
    default:
      $output .= "<div class='webform-component'>\n";
      $output .= "<label>" . $component['name'] . ":</label>\n";
      $output .= "<span class='webform-value'>".$submission->data[$cid]['value'][0]."</span>\n";
      $output .= "</div>\n";
    }
  }


  $output .= "</div>\n";

  $output .= "</body></html>";

  print $output;
}

You could extend this snippet to render whatever field types you need by adding cases to the switch.

Doing it the "right" way would likely involve creating a print template, a theming function for each field type (and webform extensions could supply their own for their field types), drupal's own CSS handling, etc.

grey_’s picture

grey_ CreditAttribution: grey_ commented

Thank you for showing it. I think It could be built on for my project :)

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Version: 5.x-2.x-dev »

This still hasn't been implemented but I'd still love to have it. With the new conditional fields patch, this may be even more important than before.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Needs work » Active

I'm currently working on an implementation that re-uses FAPI structures (similar to D7's renderable arrays) for viewing, editing, and e-mails. I'm fairly excited about this because it will allow us to remove a lot of excess code for generating e-mails.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Active » Fixed
FileSize
webform_display_rendering.patch89.78 KB

Okay here's another sweeping patch to make this implemented the "right" way. Here's the rundown:

  • Display functions are now required in all components, used for both e-mail generation and results generation.
  • Forms, submission display, and e-mails are all now generated by "renderable" arrays (similar to Drupal 7's renderables). This makes it easy to consistently build up hierarchical structures.
  • Instead of passing around $form_state to e-mails and the printing screen, we now use the standard $submission variable. This means that most custom theming done in webform-mail.tpl.php files will need to be redone.
  • However to make that easier, we now have better tokens within e-mails, such as %email[fieldsetA][textfieldB].

All in all I'm really stoked about this new approach. It makes templating much easier. We can also later make even more display modes, such as XML (maybe?) or PDF if special output is necessary. Another bonus here is that now that we have display modes in HTML, we can eventually send HTML e-mails, yay!

I've committed this change to continue moving forward with our major API changes so we can move towards alpha.

Status: Fixed » Closed (fixed)

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