My View has a default display ( of course ) and also my working PDF display called 'pdf_1'. The action provided in 'views_pdf.rules.inc' doesn't select the correct display when invoked, and the fields I see output are those configured in the default display ( the 'pdf_1' display overrides the default fields ).

The problem seems to lie here :

    // Try to get pdf display
    if (!$view->set_display('pdf')) {
      // Try the display type
      if (!$view->set_display('pdf_1')) {
        // There is definitly no pdf display

as if I change it to simply :


I get the correct display output.

Members fund testing for the Drupal project. Drupal Association Learn more


misthero’s picture

I lost many hours of my life trying to understand why the saved pdf was different from the one I was getting when accessing the views directly, you saved me!!

rbosscher’s picture

I had the same issue.
Thanks for posting, like misthero I've spended hours trying to understand why the pdf was different.

Your solution is not really working if you're having multiple displays.
I had to convert every display into a new view.

killua99’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs steps to reproduce

Dear fellow Drupal enthusiasts,

I have set this issue to "Postponed (Maintainer needs more information)".

If not already done please add an issue summary and steps how to reproduce the problem.
And please read again, "Making an issue report".

Help about how to do this can be found on IRC and in the user groups.

After there is new information, please re-open the issue by changing the status to active.

This issue was edited with the help of Issue Helper

MDJ Webdiensten’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs review
1.38 KB

I was having the same problem in latest 7.2.x version. Fixed it by rewriting views_pdf_rules_action_save() so it will always select the right display based on what you selected in the rule. Don't know if it will work in 6.x

killua99’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
Status: Needs review » Needs work

The current branch 7.x-2.x is really unstable and actually the drupal git repo is outdated, I'm working that branch on github so. Maybe you should rewrite this code into the current stable branch 7.x-1.x

I'll take a look on it.

sander-martijn’s picture

I have confirmed that manually editing 7.x.1.x in the same way as the above patch does work. Although I'm going to use it on my site because it's the last step in my project and I need to get it out the door, I hesitate to post a patch because it basically removes some error handling logic - rather I think the logic should be revisited and figure out why it's always choosing (in my case) the first pdf view instead of the one I set in rules.

for my purposes, it works now but that does not mean it will not break things for others.

sander-martijn’s picture

a bit of clarification:
either $view->set_display always returns false so that logic needs to be changed,

or the following two lines are wrong and need to be changed:
foreach ($view->display as $id => $display) {
if ($display->display_plugin == 'pdf' && isset($display->handler)) {

If I had more time I'd figure it out, but as i said, this project needs to be delivered asap so I'm just moving on for now

killua99’s picture

Bring a patch to commit it.

massiws’s picture

I also had the same problem with views_pdf 7.x-1.4 trying to save PDF.
The right display is triggered by Rules, but if there are two or more displays in the same view views_pdf don't recognize the right display.
After googling around for many hours and going down into the code, I found a possible fix: in views_pdf.rules.inc there is this code:

    foreach ($view->display as $id => $display) {
      if ($display->display_plugin == 'pdf' && isset($display->handler)) {
        $display->handler->execute($path, 'FD');

If a view has (for example) 2 different pdf display the condition:

    ($display->display_plugin == 'pdf' && isset($display->handler))

is true for 2 times, so the handler->execute() is triggered 2 times; this cause pdf file to be written 2 times (and, maybe, the second time the file isn't overwritten).

Is there a reason you have to cycle all view displays? I think that only one display needs to be considered to save the file.

So, I edit line 82 this way:

    if ($display->display_plugin == 'pdf' && isset($display->handler) && $id == $display_id) {

and this fix the problem.

Hope this helps someone to save precious time,

killua99’s picture

This patch seems legit.

I'll apply it to dev and check if everything is working, maybe release a stable one?

@vegansupreme tell me what do you thing about release a new version soon

sander-martijn’s picture

This patch was not applied to the latest security release. I had to manually patch it again. Took me days to get the right search combination to find this issue back.

vegansupreme’s picture

Status: Needs work » Needs review
544 bytes

Thanks Massiws and sander-martijn!
Here's a quick reroll of Massiws's patch. I haven't had a chance to test it though. Not sure when I'll be able to.

massiws’s picture

#12 tested on three different sites and all works fine!

  • vegansupreme committed 9b18bb8 on 7.x-1.x authored by massiws
    Issue #1423140 by massiws, MDJ Webdiensten: 'Save PDF as file on server...
vegansupreme’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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