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.
On a site with extensive use of Panels3, I also have a critical need to print to PDF.
We have a content type=Project, and a Panels treatment of the node. I have placed the PDF link onto the Panels layout, and the link shows up on the final output.
However, the print action is actually using the base node, not the Panel's layout.
Can I get the print action on the Panel level instead?
Using wkhtmltoPDF.
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#39 | 565856-panel_support_print-39.patch | 2.74 KB | brockfanning |
Comments
Comment #1
jcnventura CreditAttribution: jcnventura commentedCan you provide a URL to the page?
Comment #2
boabjohn CreditAttribution: boabjohn commentedHowdy JCV: thanks for checking...the page is behind a security layer at the moment. It's a normal panel page, and as merlinofchaos notes, panel pages are not nodes.
The Print module can be invoked with printpdf/[nodeID] (only?)
So there seems to be no way to address the current state of the user's screen, which is being rendered though Panels, not through a node.
Have you been able to get a panel page to print with wkhtmltopdf?
Thanks, JB
Comment #3
jcnventura CreditAttribution: jcnventura commentedNo, you can also access pages via printpdf/path.
To show links in those pages you need to enable the appropriate setting in the module settings.
Comment #4
boabjohn CreditAttribution: boabjohn commentedAhhh! That sounds like the go: but where in the settings? I've been through the common settings and the PDF settings. Sorry for being blind, but can you please show me where to change/set this?
Thanks!
Comment #5
boabjohn CreditAttribution: boabjohn commentedRight: never mind...found it!
PDF Settings> Advanced options> Use URL alias instead of node ID
Sorry for the hassle...
FWIW, I started a thread over with the Panels people as well on this point: I'll share this tidbit with them.
Thanks again,
JB
Comment #6
boabjohn CreditAttribution: boabjohn commentedBut: we're back.
Yes, even though the option is ticked, and the bottom of the PDF shows that it used the URL and not the node ID, the proble is that it is still feeding off of the *nodes content* vs all the rich relational content I have dragged into the panel page.
The panel page is rendered whenever a node of type x is called.
So the node content is one layer
The Panel pages sits on top and assembles views etc (along with native node content).
What I want is for the user to get the Panel page assembly, not just the node content...and the URL path trick is not doing the trick (sad to report!)
JB
Comment #7
boabjohn CreditAttribution: boabjohn commentedJust to complete this one...
There's no underlying problem with any of the Print module gear here. The hard fact is that producing a nice PDF version requires hand coding of a specific template.
We opened up our nice Panel page display and went through each content area, creating php calls in the pdf template. If we make changes to the cck/node/view assembly, then these changes have to be separately managed in the PDF template as well.
Closing...
Comment #8
Exploratus CreditAttribution: Exploratus commentedI agree with #6. Printing just node content vs a cobination of views / node content is very different and very important. I want to be able to pdf print a particular set of views.
Is is possible to print a particular set of views related to a node with the module as it stands now? Considering trying it out, but if it can print a certain type of views, wont do me any good.
Any suggestions?
Comment #9
boabjohn CreditAttribution: boabjohn commented@whatmetropolis: as I understand it, thesystem works as follows...
1. The prin module takes the url (with node value) and has a quick look for any custom print stylesheets that might exist *for the target node type*.
So if you're printing a node of type = media_release, Print will look for a media_release-print.tpl.php (or something close to that)
2. This template can carry whatever php you wish to include...which means you can call whatever views with whatever parameters you're able to code for.
So on the one hand it's a manual coding job, buit on the other you get to do whatever you like...
A themer is probably the person you need. Someone to connect the views with the print tpl.
HTH.
Comment #10
Andy_Read CreditAttribution: Andy_Read commentedThe Print/PDF module is great, but like others before me I've hit this same problem.
From my own experiments, it appears that the module is quite happy to render the output of a regular Panels page with a dedicated url path, it's just when using a Panel node that the Print module 'chooses' to use the raw node instead of waiting until Panels has done its stuff.
I'm going to dig into the code a bit, but in principle it seems that the Print module is quite capable of rendering the Panel node output but maybe needs a switch to tell it to do this instead of the raw node. Everyone on this thread would probably say it should default to taking the output from Panels, just as you see in the browser, but if a switch is needed it could be in the print settings or even per content type.
Andy
Comment #11
Andy_Read CreditAttribution: Andy_Read commentedYes, indeed! There may be subtleties I'm not yet aware of, but looking at print_controller() in print.pages.inc, the code has 3 options to process the page: _print_generate_node(), _print_generate_book() and _print_generate_path(). The current logic gives the simple node generation priority, then book (not sure how that differs) and finally path is treated like a poor-man's fallback. A quick hack to make _print_generate_path() the first choice happily created print and PDF versions of a Panels node page.
So it's just a case of refining this logic with some admin settings...
Andy
Comment #12
Andy_Read CreditAttribution: Andy_Read commentedHaving re-opened this issue, I've re-linked and highlighted this update on the duplicate issue #890596: How to print Panels output?.
As previously stated, it's simple to patch the print_controller() function to use the Panels output for nodes, but I wanted to get some input on reqs/spec before suggesting a specific patch. When should the print module take Panels output rather than node-specific output?
What additional admin setting might be required according to your use-cases?
Comment #13
ayalon CreditAttribution: ayalon commentedI wrote a patch, that implements panels support.
It's only a few lines long.
I think it's better, not to change the logic of the print_controller(). The patch has only a impact, if panels is installed.
Comment #14
boabjohn CreditAttribution: boabjohn commentedHi guys...as the issue originator 1.5 years ago (!) it's great to see the new thinking here...especially appreciate andy_read and ayalon grabbing the issue by both ends and having a go.
I'm a non coder: it looks to me like there is the stub of an idea offered by the existing option to: PDF Settings> Advanced options> Use URL alias instead of node ID
Isn't this the "switch" point needed? The problem (back in 2009) was that despite using this option we still got the raw node.
If the #13 patch forces PrintPDF to use the URL alias (ie, the final rendered page) that means there's no need for additional interface/management work. Just add a comment to the Use URL option noting the effect of providing a solution for Panels (and other rendered elements).
Comment #15
dogboy72 CreditAttribution: dogboy72 commentedPatch in #13 works well. I had been using custom .tpl files (i.e. print_pdf.node-MY_CONTENT_TYPE.tpl.php) but the patch defaults to the print.tpl.php. Anyone know if there is a way to override this and create custom tpl files?
Comment #16
StratisFear CreditAttribution: StratisFear commentedCan someone adapt this patch to print_mail.inc file so that it works with send mail and not just print?
Comment #17
HnLn CreditAttribution: HnLn commented#13 also seems to work for d7 except that the check on the page callback should be for 'page_manager_node_view_page' (line 95).
Comment #18
jcnventura CreditAttribution: jcnventura commentedComment #19
rfulcher CreditAttribution: rfulcher commentedI have put this patch in place and see no difference. I have a panel with a node displayed and a view at the bottom. I really need the PDF & Print & Email to include the view at the bottom....Help I am new to this so I am hoping I put it in the right spot in the file.
Comment #20
dhayalan_ms CreditAttribution: dhayalan_ms commentedIt can be easily achieved by having no hacks using print.node-type.tpl.php
Just follow the steps mentioned below
1.copy print.node-type.tpl.php into theme
2.Create a function as follows in template.php
3.In print.node-type.tpl.php replace
print $print['content']
intoprint get_panel_view($print['node']);
4.Rebuild theme cache
5.You are done
Comment #21
dreamer777 CreditAttribution: dreamer777 commenteddhayalan_ms. thank you very much! you made my day!
#20 works perfect for print page. I will try it for pdf and e-mail also and let you know.
Comment #22
dadderley CreditAttribution: dadderley commentedHave you made this work with Drupal 7? The same problem exists there as well.
Thanks in advance.
Comment #23
dhayalan_ms CreditAttribution: dhayalan_ms commented@dougzilla ,Sorry I havent tried in Drupal 7, I will look into it and let you know inb couple of days
Comment #24
dadderley CreditAttribution: dadderley commentedThank you.
I really appreciate you revisiting this issue.
Comment #25
annikaC CreditAttribution: annikaC commentedHi dougzilla,
Stumbled across this while looking for the same thing - thanks to dhayalan_ms for D6 code, here's that function for D7:
Template should be called print--node--[type].tpl.php. Hope that helps you or anyone else with the problem out!
Comment #26
dadderley CreditAttribution: dadderley commentedHi annikaC,
Thank you.
This is lovely. It does have a quirk though.
When logged in as user 1, it works perfectly.
When not logged in or logged in as another user, this error shows up when I hit the "printer friendly" and "pdf version" links.
In my template file, line 25 is in here.
Have you encountered this?
I looked at the permissions, everything should be good.
Comment #27
annikaC CreditAttribution: annikaC commentedGood spot! I will have another look at this tomorrow as it was for one of my current projects :)
Comment #28
dadderley CreditAttribution: dadderley commentedCool and thanks again, I am pretty excited about this.
Comment #29
annikaC CreditAttribution: annikaC commentedBack again - I am uncomfortable with this solution but it works - anyone got a better way? Does it work for you dougzilla?
Comment #30
dadderley CreditAttribution: dadderley commentedYes annikaC it works for anonymous and authenticated users.
Good work, thank you.
Comment #31
Peacog CreditAttribution: Peacog commentedHi annikaC and dougzilla
I'm trying to use your code but I can't get it to pick up my template. I've tried print--mynodetype--.tpl.php and print--mynodetype.tpl.php. What's the correct format? Thanks.
Comment #32
Peacog CreditAttribution: Peacog commentedI should have read the README first. All the valid formats are there. For a content-type specific template it's print--node--[type].tpl.php. For a format specific and content type template it's print--[format]--node--[type].tpl.php for example print--pdf--node--article.tpl.php.
Comment #33
dadderley CreditAttribution: dadderley commented@Peacog
Just saw your post.
Glad you figured it out.
annikaC rocks!
Comment #34
jwilson3I tried the patch in #13, updating it for Drupal 7, but it doesnt work appropriately, because as soon as you enable Panels node variants, the page callback gets added *everywhere* even if the current node type doesnt have a variant. Thus, I've gone with the other more recent code snippets, but have cleaned them up a bit to take advantage of not having to generate the content twice, as most of the examples above do.
This example implements hook_preprocess_print() function, and can be placed in your theme, without having to modify the print templates at all, as it modifies the $print['content'] variable, before getting to the template layer.
I'm placing this as CNR, because this currently only handles the "node_view" panels, and doesn't work for other object type variants like User pages and taxonomy term pages that could possibly also be using Panels for render as well.
Comment #35
bradjones1Bumping this to 7.x since there doesn't seem to be consensus code for 6 and a good solution can likely be backported.
By my analysis this issue boils down mostly to selecting (and using) the proper menu router callback for the node in question, much as would happen by default for a non-node custom page. So why not just set an option for nodes to bypass their special handling in print module and just consult the menu router as to which callback to use?
See attached patch. Thanks!
Comment #36
developerweeks CreditAttribution: developerweeks commentedPerfect timing for this patch and discussion, attempting this patch on 7.x-2.0-beta2.
I think either I missed something, or there is a step missing in the patch. Something in my site is not handling this as expected. Attempted the pdf print gives me an end result of 'The requested page "/printpdf/234" could not be found.'
I tried tracing this workflow, and I am wondering how this patch is supposed to accomplish the pdf render of the panel. I see how this excludes the removal of 'node' from the front of the path, and how this prevents the call of _print_generate_node, thus forcing the print module to use _print_generate_path.
However, from the behavior of my browser I have to assume _generate_path is failing and I am seeing the alternate:
$node = print_controller($path, $link['format'], $cid, $view_mode);
if ($node) {
...
}
else {
return NULL;
}
Triggering this catch:
$pdf = print_pdf_generate_path($path, $query, $cid, $pdf_filename . '.pdf');
if ($pdf == NULL) {
drupal_goto($path);
exit;
}
Far back in scope where $path equals "234" (never passed by reference).
And since drupal_goto("234"); does nothing, I get my error message.
If I do not alter the line
if (ctype_digit($parts[0]) && ((count($parts) == 1) || $revision_view)) {
then the pdf link only refreshes the page.
Is this patch working for some one else?
Comment #37
jwilson3On a separate project from the implementation I used/suggested in #34 and so I had an opportunity to try out the patch in #35, with Panelizer for the node rendering, instead of normal Panels node_view variants.
I can concur with #36. The patch only works when you enable the setting "Use URL alias instead of node ID" on admin/config/user-interface/print/ui "Advanced link options".
If you try to use printpdf/[nid], you end up with an error, but if you go to printpdf/[node-alias] (assuming you have pathauto configured) everything works great.
Additionally, if you go to printpdf/node/[nid] the patch works fine as well.
It all has to do with the stripping of the "node/" from the URL.
Comment #38
jwilson3I edited my comment above because I found the same bug as #36. CNW
Comment #39
brockfanning CreditAttribution: brockfanning commentedHere's a slight tweak of bradjones1's patch, to address that page-not-found issue.
By the way, the approach bradjones1 uses strikes me as something that should just be the default, with no need for a UI checkbox. Is there any downside to consulting the menu router like this 100% of the time?
Comment #40
Yuri CreditAttribution: Yuri commentedWhen I apply patch #39, it does not have any effect and pdf print still shows only the node contents, not the panel panes of the node virant panel. Does any of you have success with latest print module dev. and panels?
Comment #41
Yuri CreditAttribution: Yuri commentedComment #42
bradjones1@Yuri - did you toggle the checkbox this patch adds to the admin config ("Consult menu router..."?)
Comment #43
Yuri CreditAttribution: Yuri commented@bradjones1 Thank you, after checking that box, the page indeed shows up in the generated pdf.
However, that includes also some panes and also the 'text format' information..is there a way to select what appears and what not?
Thanks!
Comment #44
bradjones1@Yuri - I'm not entirely sure what you mean by extra panes and test formats... but I suppose you could implement a print stylesheet in addition to using this module. Regardless, I think given you're feedback it's safe to put this back to "needs review."
If a maintainer could take a look at this since it seems to work for multiple others?
Comment #45
baschke CreditAttribution: baschke commentedthe patch from #39 isnt't working with the latest version of the module.
I get an error when patching:
could anyone have a look into this?
Comment #46
dobe CreditAttribution: dobe commentedPatch in #39 worked for me. Thankyou!
-Jesse
Comment #47
mccrodp CreditAttribution: mccrodp commentedPatch in #39 did work for me and also applied cleanly to the latest dev version from git repo. The new option will work with Panels that override the node content area such as Panelizer in my case. But it will not work with Panels Everywhere module.
Comment #48
candelas CreditAttribution: candelas commented@baschke the errors that you get are because you applied to version 7.x.1-dev or whatever of the 1 release. This patch work for the 7.x-2.x-dev
#39 worked for me too.
Comment #49
candelas CreditAttribution: candelas commentedI tested in last Open Atrium distribution and works with one patch to fix a couple of things (if you are interested, look in the OA_print module issue cue).
Thanks to all for collaborating making this patch. The only thing is I would never have guessed that that change on the menu router would let me print with Panels. So much to learn in Drupal!
I think this is an important patch to communicate two solid modules as Print and Panels, that are with us for many years, always updating and letting us work faster. It would be very good if this is included in Print.
Comment #50
jwilson3based on #49, yes, this would be a pretty major win.
Comment #51
katrien_w CreditAttribution: katrien_w commented@Candelas: could you be so kind to provide steps to get print working with Open Atrium, for instance for a panelized OA section page.
OA print only prints document pages as far as I know?
Which pdf library do you use?
Comment #52
candelas CreditAttribution: candelas commented@katrien_w here #2452737: OA Print: update to Print 2 and apply a patch to work with Panels I explained, point the patches I used and made one. If you have any doubt, I think it is better to answer there to centralize the information :)
Comment #53
boabjohn CreditAttribution: boabjohn commentedG'Day all,
Nice to come back to a healthy and productive discussion after 6 years! It turns out a current project could very much use this feature so here I am again to see what has been offered up by the ever-generous Drupal Community.
This is likely to be a personal problem, but I've tried clearing out my local repo and re-installing the latest 7.x-2.x-dev, and then applying the #39 patch. I got what looks like partial success:
Would there be an obvious explanation for this unexpected ending? I'm not a patch master...
Thanks in advance for any clues.
Kind regards,
JB
Comment #54
boabjohn CreditAttribution: boabjohn commentedAlso, @mccrodp, what was the specific problem you were seeing with Panels Everywhere, referenced in #47?
We're often in the position of needing to wrap PE around a site.
Comment #55
mortona2k CreditAttribution: mortona2k at Forum One commented@boabjohn
I just tried
patch -p1 < 565856-panel_support_print-39.patch
Patch applied cleanly for me, from within the print module directory.
Comment #56
katrien_w CreditAttribution: katrien_w commentedHello, thanks for all the usefull efforts in this discussion.
A single panelized page prints flawless with the latest patch. But when I'm using the 'printfriendly version' on a book page, I'm still getting the node contents of the parent page and its children in one list, instead of the panelized page versions.
I know that the print module should be taking over partly the print function of the book module.
I'm not a coder. Maybe someone can help me on this?
Comment #57
mccrodp CreditAttribution: mccrodp commented@boabjohn - Sorry for delay, I don't have access to the project I was working on anymore and I cannot remember to give you exact info.
I remember I figured out why, but did not find a solution as far as I remember. It was either that Panels Everywhere uses a different preprocess function or tpl file to Panels / Panelizer. So, it only looked into the content region that Panels / Panelizer overrides rather than say blocks that are added by Panels Everywhere to the content region or elsewhere. Good luck!
Comment #58
P2790 CreditAttribution: P2790 commentedThe patch works great for me, but I am losing the Node Title on my panelized content types. I have a workaround where I hide provide the title from a panel pane and put the title in the content area of the panel. I am using panelizer and the bootstrap theme, although having tested other themes it is not theme related.
Comment #59
P2790 CreditAttribution: P2790 commentedChanging to needs review.
Comment #60
izmeez CreditAttribution: izmeez commentedI would appreciate some clarification on naming conventions for custom theme template files.
The README.txt file suggests naming the files as:
print-node-content-type.tpl.php
Meanwhile comment #9 above #565856-9: Can Panel pages be sent to PDF for rendering? suggests naming custom template files as:
content-type-print.tpl.php
and suggests that the module automatically uses these custom template files if they exist for different content-types allowing them to be used for printing panels layouts and other enhanced layouts rather than simply printing the node.
There may be specific advantages and use cases for the different naming conventions.
There is also a suggestion in comment #14 above #565856-14: Can Panel pages be sent to PDF for rendering?
that what is needed is simply a help comment
Would it be useful to add a few lines to the help for the module?
A separate issue could be started for that purpose.
Comment #61
izmeez CreditAttribution: izmeez commentedFollowing on comment #60, I have created a separate issue to enhance the help documentation and at the same time make it available when the README.txt file is not readable #2787263: Provide print module help when README.txt file not readable on some production sites.
Comment #62
wizonesolutionsIMO this patch is Good Enough™. Worked for me as I expected. I vote for getting it in.
Comment #63
pinueve CreditAttribution: pinueve commented+1 patch #39 works perfect, but it does apply on 7.x-2.0 and NOT on dev version
Comment #65
jcnventura CreditAttribution: jcnventura commentedFixed #39 to make it apply, and committed it. Thanks everyone!
Comment #66
P2790 CreditAttribution: P2790 commented@jcventura
See my comment:
Can anyone else confirm they have this issue?
Comment #67
daggerhart CreditAttribution: daggerhart as a volunteer commentedThis is off topic from the submitted patch, but I thought it might be worth showing an alternate approach. I created a panels rendering pipeline that uses functionality provided by the print_pdf module.
https://github.com/daggerhart/panels_printpdf
Comment #68
crutch CreditAttribution: crutch commentedDaggerhart, I tried panels_printpdf, it still renders only the node and not the panel content including any views. Also, it dedicates the Panel variant as only a PDF and so you are unable to view the page. Maybe I'm doing something wrong, however I like the approach and it works to render a panel variant as a PDF and has a straight forward configuration.
Comment #69
crutch CreditAttribution: crutch commentedPatch #64 on 2.x dev seems to be working well after a few days of getting familiar with the current state and getting things configured properly, thanks!
Comment #70
crutch CreditAttribution: crutch commentedYes I can confirm the same @#66.
The title will display when removing
<?php if (!isset($node->type)): ?>
and<?php endif; ?>
around the h2 print-title in the tpl.phpComment #71
P2790 CreditAttribution: P2790 commented@crutch, thanks for that, which tpl file do you mean? Is it the one in the module, print.tpl.php
Comment #72
crutch CreditAttribution: crutch commentedyes, however I copied print.tpl.php over to sites/all/themes/mytheme/templates folder and then made the customization there.
I now have print--pdf.tpl.php and print--html.tpl.php in my theme (flush caches after copying and every time after changing code in those files to activate them).
Comment #73
jcnventura CreditAttribution: jcnventura commentedFixed, as per #65
Comment #74
jcnventura CreditAttribution: jcnventura commentedComment #76
kopeboy CreditAttribution: kopeboy as a volunteer commentedI don't understand how I can print the Panel output of the node.
I've updated to dev version of the module.
And it doesn't work out-of-the-box:
the pdf print i'm testing is still showing the node content and not anything else I've added to the panel variant.
Then I tried adding the function of comment #29 in my theme's template.php file
Then I tried replacing 'print $content' with 'print get_panel_view($node)' in the module's print.tpl.php
(I don't have any node template in my theme that is overriding that)
And the result is still the same.
Can anybody help please?