Compatibility for Print module.
NikLP - January 4, 2008 - 17:42
| Project: | Custom Pagers |
| Version: | 5.x-1.9 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Pagers are irrelevant in print-friendly pages. You can obviously use CSS to remove the links from the node, but that doesn't remove them from what the Print module sees.
Fortunately, Print offers a flag to test against - $node->printing. I have created a patch for custom_pagers that checks against this flag before any real work is done by that module, so that no pagers are added to Print's pages.
| Attachment | Size |
|---|---|
| custom_pagers.print_.patch | 555 bytes |
#1
Anyone want to let me know if this is best practise, or stupid, or can be done another way? Anyone using this combination of modules is sure to need this patch, but I'm not sure about how interrelating modules like this is viewed...
Ta!
#2
This is in HEAD now -- I'll mark this fixed.
#3
Can you comment on the "best practise" element of this issue tho? I mean, is "$node->printing" a standard variable, or specific to the print.module?
I can see why there could be potential outcry for writing in module interdependencies like this, if it's specific.
#4
I'm afraid I don't know the answer to this. I just looked at the CVS stuff, saw it there, and marked the issue. The simplest way to test it that I can think of is to configure your test site (you do have a test site?) to not have the print module, and see what happens.
I do note that a patch I received over at the Shared Sign-on project calls a function called "function_exists". I don't know whether that has any implications here or not.
http://drupal.org/files/issues/singlesignon_0.patch
#5
No, it doesn't matter about the function existing - my patch does not execute any function. It just checks a variable, and given the fact that it will definitely not be "true" unless something has set $node->printing, nothing bad will happen.
It would be interesting to try to get a "proper" answer to this, though. Maybe one of the modules in question should be checking something around the hook_nodeapi() and the "print" hook?
I refer to: http://api.drupal.org/api/function/hook_nodeapi/5
Bit beyond me at the moment unfortunately.
#6
Automatically closed -- issue fixed for two weeks with no activity.