The module doesn't respect what jquery update module does.
First guess - the module doesn't use normal preprocess page queue.

As a result, when printing anything which uses latest jQuery available to D community, it fails.

Example. Using gmap, see no maps on printing page and errors in FF console, like: $.support is undefined
Replacing misc/jquery.js with the symlink to /sites/all/modules/jquery_update/replace/jquery.min.js fixing the problem.

CommentFileSizeAuthor
#6 print-preprocess-953920-6.patch6.43 KBgrndlvl
#5 print-preprocess-953920-5.patch6.81 KBtheunraveler

Comments

jcnventura’s picture

jcnventura
Primary language English
commented
Title: Is not compatible with jQuery Update » Make print.tpl.php a true template (solve compatibility with jQuery Update)
Status: Active » Postponed

The module is now calling the correct page preprocess functions, but that info is only processed after the print['scripts'] variable has been defined.. jquery_update tries (and succeed) in deferring this to the very end, even after the module has run..

The solution for this is something that has been on my mind for some time: make the print.tpl.php file a lot more like the Drupal page.tpl template and get rid of all the hard-coded HTML in the module.. However, this will break compatibility with existing templates.. This is one of the things I want to tackle in the near future.

ydx’s picture

ydx commented

The module is now calling the correct page preprocess functions

hello, jcnventura.
I use Custom Node Template to set serveral styles of node, but when I click print button it just give me the original node view,anyidea, thanks?

jcnventura’s picture

jcnventura
Primary language English
commented
Version: 6.x-1.9 » 7.x-2.x-dev
Status: Postponed » Fixed

Finally, made the template a real template.. The scripts variable is now set at hook_preprocess_X() time, so if the jquery update is fixable, this triple-bypass surgery I just completed on the core of the module should do it.

Status: Fixed » Closed (fixed)

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

theunraveler’s picture

theunraveler commented
StatusFileSize
new print-preprocess-953920-5.patch6.81 KB

Here's a patch that fixes this issue for 7.x-1.x.

grndlvl’s picture

grndlvl commented
StatusFileSize
new print-preprocess-953920-6.patch6.43 KB

Re-rolled as relative path.

David_Rothstein’s picture

David_Rothstein commented 
+  if (variable_get('print_html_sendtoprinter', PRINT_HTML_SENDTOPRINTER_DEFAULT)) {
+    drupal_add_js();

I'm not sure what that drupal_add_js() call does... isn't it a no-op?

But the patch seems to work (I think because in Drupal 7, core JavaScript happens to get added on pretty much every page load already anyway).

theunraveler’s picture

theunraveler commented

Actually, the core JS files are loaded on the first call to drupal_add_js(), so I think this is just ensuring that those are added before inlining the send to printer JS.

David_Rothstein’s picture

David_Rothstein commented

That only happens if you pass something in as the first parameter of drupal_add_js(). Otherwise it looks to me like it does nothing.

My guess is that #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page is what's making this work, but either way, it seems to :)