Closed (fixed)
Project:
Printer, email and PDF versions
Version:
6.x-1.3
Component:
User interface
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
2 Mar 2009 at 04:08 UTC
Updated:
16 Apr 2009 at 18:57 UTC
Jump to comment: Most recent file
Comments
Comment #1
jcnventuraHi,
That's weird... The module loads the node as stored by Drupal and executes the same calls to render the content as Drupal does.. Where are you placing that PHP code?
João
Comment #2
Rosamunda commentedHi! Thanks for your reply!
At the bottom of the node. It´s still inside the content area.
I know that the code should appear, because I´ve printed a prefix, something like:
And the
<b>Telephone: </b>does print.Comment #3
Rosamunda commentedSorry, forgot to change status :)
Comment #4
jcnventuraI took a look at it, and sincerely, I think the problem may be in your code.
That code is assuming that you'll have the $user variable available to you when it runs. When I put a
print $user->uid;in the body of one of my pages (with PHP filter enabled), nothing comes out..However, if I declare
global $user;before I use that variable then, indeed, my UID is printed.
Can you try to add that global declaration to your code? I am unwilling to do it in the print module, as that would mean that I would have to declare all of them in the long-run. And since I just proved to myself that that variable is not pre-declared global inside the context of the PHP filter, I would prefer to follow Drupal core and not pre-declare everything.
João
Comment #5
Rosamunda commentedSorry for the big delay in responding to this, I was working on it though, and discovered this:
You´re right, the problem was in my code. With
global $user;it works.(so I´m changing this to support request because isn´t a bug) :)
And while trying this, it ocurr to me that the funky code could be replaced with an embedded view (ViewField), and tried that also.
If you could replace all that with a cck view, you wouldn´t need to touch anything in print´s code, as it is right the way it is now.
But in the second case (the embedded view), it needed an argument that referred the view output with the node id of the node. And in this case it won´t work. It seems that it just won´t show anything that depends on the current´s node situation (ie. a filter with a current´s group selected).
My initial question was solved, and it hasn´t anything to do with print, it was my own error. I apologize for creating this as a bug.
Could it be my own stupidity again with this views issue? because the print page actually shows the node id number in it.
Thanks again!!
Rosamunda
Comment #6
jcnventuraSorry for not answering it sooner. I am not a heavy user of Views, so I am not really understanding the problem with the embedded view.
Just a reminder that the printer-friendly version is being generated by the print module, based on the contents of the original node. BUT IT IS A DIFFERENT PAGE. It isn't even a node.. So, if your view is somehow trying to get information on the current node, it will probably fail.
I can try to see if there's something that can be done by the module, but I need a simple sequence of steps to reproduce the embedded view that's showing the problem on my site. Then I can try to debug it and understand the exact nature of the problem.
João
Comment #7
Rosamunda commentedThanks for your answer. I´ll try to be as detailed as possible.
I´ve installed ViewField (is a CCK field module that allows administrators to put views directly into nodes).
I´ve added two viewfields inside the pages (content type page), that references all content of a certain type inside a certain group (organic group).
The items that appear in the viewfield should match the current node´s group.
I´ve tried several ways of creating the view, trying to avoid the use of arguments or relationships, but it is not possible. I´m attaching two print screens of the views configuration
I thought it could have something to do with the special path that I´ve created to all pages (not the simple node/nid, but I´ve changed it with pathauto), but the print view follows the same path, with no results, so I think, the problem isn´t there.
So, after trying a lot, I think, it has something to do with the arguments. As you´ve said the print version isn´t a node at all, so it seems that it won´t recognize the arguments inside that node.
Is there anything that can be done about this?
Thanks again for all your help and advice!!
Rosamunda
Comment #8
Rosamunda commentedSorry, forgot to add the attachments.
Comment #9
Rosamunda commentedDidn´t let me add the two at a time..
Comment #10
jcnventuraI still have to try what you described, but from your description, I think that the real problem would be the one you reported in #385994: Printer-friendly pages do not inherit group membership from original page.
João
Comment #11
Rosamunda commentedHmmm, maybe you´re right. I mean, it all happens when I try to get some stuff from inside a certain OG.
Sadly, OG issue queue isn´t as fast as I would like it to be :)
Thanks !
Comment #12
jcnventuraI can confirm that the problem is the group, so I am closing this one and following the fix in the other issue (#385994: Printer-friendly pages do not inherit group membership from original page).
João
Comment #13
Rosamunda commentedThanks for keeping this problem alive and kicking João
I´m following that other post too :)