Don't know what the actual problem is, but i have a bunch of viewfields that use the views 'node id from url' option when providing a default argument and the view doesn't print.

The workaround is to select 'php code' for the argument and enter return arg(1); in the code box.

Don't know whether is a views, viewfield, or print problem-- but this is where I searched for a solution so I figured I would post this here and hopefully save some others time tracking this down.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

anrikun’s picture

I have exactly the same issue.
"print" breaks arg() function.
I think it should try to rebuild the $_GET array so that there is no problem using viewfields, view reference, etc.

anrikun’s picture

Status: Active » Needs review
FileSize
431 bytes

Here's a patch that seems to fix this issue.

johnv’s picture

subscribe.

anrikun’s picture

Title: viewfield with 'node id from url' argument not printing » Viewfield or View reference with 'node id from url' argument not printing
johnv’s picture

anrikun, I tried your patch (on my D7-installation), but it didn't work. The work-around doesn't work either.
But Joao wrote that D7 did not have all features yet..
I already had posted my problem here: #1104174: Support for View Reference; they might be duplicates.

Your patch might also be the remedy for other issues like:
#1049168: Correct node path error in print_mail_node_view()
#1061636: If node url begins with a number then print_mail returns "Access Denied" despite permission settings

anrikun’s picture

Patch at #3 is only for D6 (same as the Version value of the issue).

johnv’s picture

Yes, but the D7-code is identical on that spot.

anrikun’s picture

I guess I should investigate further D7 version of Print... once I get some time :-)

nilla054’s picture

I tried the patch #2 for 6x but it didnt work. Any updates on this issue for 6x

anrikun’s picture

@nilla054:
Are you using Viewfield or View reference?

nilla054’s picture

I am using plain views. I programmatically embed a view block in node templates. The view takes an argument (php code) something like :

if (arg(0) == 'node' && is_numeric(arg(1))) {
$nid = (int)arg(1);
$node = node_load($nid);
return $node->uid;
}
else {
return 0;
}

The node templates prints the view block fine, but the print module doesnt

anrikun’s picture

Could you add a debug message here:

<?php
print '['. arg(0) .';'. arg(1) .']'; // here
if (arg(0) == 'node' && is_numeric(arg(1))) {
    $nid = (int)arg(1);
    $node = node_load($nid);
    return $node->uid;
}
else {
    return 0;
}
?>

It should display arguments.
Tell me then.

jcnventura’s picture

Status: Needs review » Needs work

There's a lot of places where the module will get the value of _GET['q']... I am not sure of the side effects of #2 at the moment..

anrikun’s picture

@jcnventura:
I don't really understand why you revert this to "needs work".
Have you identified any actual side effect yet?
Why not let this as "needs review" meanwhile? "Needs work" prevents people from testing it.
This should be reverted to "needs work" only if the patch actually breaks something or doesn't work.
For my part, this patch has been working flawlessly on one of my production sites for about 6 months now.

jcnventura’s picture

The place where the _GET change is one of the starting points of the module.. I would have this change be moved into some place not so central and closer to the point where this is needed.

Marko B’s picture

Adding #2 helped me aswell.

anrikun’s picture

@jcnventura (#15)
Well I don't agree.
As for me, this is the opposite: the sooner $_GET is rebuilt the better it should be. This ensures that any module using arg() will get the expected arguments whether the path starts with 'print/' or not.
Once 'print/' has been caught, that is after menu routing is done and the 'print' callback is being run, it should not be necessary to keep it in $_GET any longer.
But this is only my opinion and as it is your module, you're the boss jcnventura :-)

jcnventura’s picture

@anrikun: It's not a matter of agreeing or not.. The module does some stuff before it finally asks Drupal to execute any render / hook. In some paths, it uses the $_GET variable to find out how it was called. Inserting it this early may break stuff. Inserting it later after the possible paths are fewer and it's easier to understand what are the consequences, but before any Drupal hook is called is, in my view, a lot safer.

Harry Slaughter’s picture

I'm using version 6.x-1.15 and seeing the same behavior described above.

I have several views that require arg() values and they work fine when viewed on the website.

However, when print.module renders a printer-friendly page (can't speak to the PDF version), all the views content is missing.

UPDATE: I tried to reproduce the problem in a local testing environment. I included a view tab in a quicktab config. It displayed properly on the page and also showed up in the printer-friendly display.

So my problem has to do with some of the custom code that is generating the quicktabs. Good news for print module, bad news for me.

rafaticarte’s picture

Version: 6.x-1.x-dev » 6.x-1.8

I'm using version 6.x-1.18 and I have same behaviour, I have missing arg() values.

Any other solution?

Thanks.

anrikun’s picture

Version: 6.x-1.8 » 6.x-1.x-dev
FileSize
575 bytes

Here is patch at #2 updated for latest 6.x-1.x-dev

mxlav’s picture

Issue summary: View changes

I just encountered this in D7 site.
Using view references to display data on a custom content type.
D6 patch didn't seem to change anything.
Is there someone who got this to work?

jboeger’s picture

I have tried the patch for Drupal 7 but cannot get it to work.

I am trying to get a viewreference field to appear in the print version / pdf version of node, but it just doesn't appear. Same thing using the /entity_print module. Anyone have any ideas?

jcnventura’s picture

Closing all issues related to the Drupal 6 version of the print module.

jcnventura’s picture

Status: Needs work » Closed (outdated)