Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#16 | webform_display_rendering.patch | 89.78 KB | quicksketch |
#1 | webform-5.x-1.7_printable.patch | 2.32 KB | HorsePunchKid |
webform-5.x-1.4_printable.patch | 2.27 KB | HorsePunchKid | |
Comments
Comment #1
HorsePunchKid CreditAttribution: HorsePunchKid commentedRerolled for the 1.7 release, in case anyone is interested.
Comment #2
Rowanw CreditAttribution: Rowanw commentedWhat about using a print stylesheet? Works for me.
Comment #3
holydrupal CreditAttribution: holydrupal commentedIt wont work for version 5.2
any idea how we could print a simple webform by print-friendly module?
Comment #4
quicksketchI'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.Comment #5
holydrupal CreditAttribution: holydrupal commentedI 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.
Comment #6
canen CreditAttribution: canen commentedAny update on this?
Comment #7
xjmTracking.
Comment #8
xjmI 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.
Comment #9
quicksketchxjm, 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.
Comment #10
xjmWell, 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.
Comment #11
grey_ CreditAttribution: grey_ commentedxjm #10 You don't happen to have that little hack available? I would very much like to see it :)
Comment #12
xjmAlright: 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:
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:
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.
Comment #13
grey_ CreditAttribution: grey_ commentedThank you for showing it. I think It could be built on for my project :)
Comment #14
quicksketchThis 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.
Comment #15
quicksketchI'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.
Comment #16
quicksketchOkay here's another sweeping patch to make this implemented the "right" way. Here's the rundown:
%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.