I had originally opened this issue where javascript was running on certain pages. http://drupal.org/node/880138

I have since updated to 6.1.11 and wkhtmltopdf 0.10.0 beta5 and now javascript is not running on any of the PDFs I output.

As steps to troubleshoot I included a quick script in the header of print.tpl.php.

   <script type="text/javascript" charset="utf-8">
      $(document).ready(function() {
        $('img').hide();
      })
    </script>

On the html (webpage) output the images are hidden on the PDF the images still appear SO javascript is just not being executed.

Comments

2ndmile’s picture

In recent log entries I found,
wkhtmltopdf: Loading pages (1/6) [> ] 0% [======> ] 10% Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file [=======> ] 12% Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: file:///tmp/wktemp-22c736c0-3e3f-40e0-beed-752baefbc0c2.html:23 ReferenceError: Can't find variable: jQuery Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file [=======> ] 12% [========> ] 14% [==========> ] 17% [===========> ] 19% [=============> ] 22% [===============> ] 25% [================> ] 27% [=================> ] 29% [===================> ] 33% [======================> ] 37% [===========================> ] 45% [==============================> ] 51% [========================================> ] 68% [==============================================> ] 77% [============================================================] 100% Counting pages (2/6) [============================================================] Object 1 of 1 Resolving links (4/6) [============================================================] Object 1 of 1 Loading headers and footers (5/6) Printing pages (6/6) [> ] Preparing [===============> ] Page 1 of 4 [==============================> ] Page 2 of 4 [=============================================> ] Page 3 of 4 [============================================================] Page 4 of 4 Done

2ndmile’s picture

OK.... interesting. I realized that the number of "Warning: Blocked access to file" corresponded directly to the number of Javascript and CSS files that were on my site. Decided to test this by turning on JS and CSS optimization and output another PDF. This was the output in the Recent Log Entries:

wkhtmltopdf: Loading pages (1/6) [> ] 0% [======> ] 10% Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file [==============> ] 24% Warning: file:///tmp/wktemp-60b5e843-b86e-4f5a-9a9b-900d90efaf4d.html:11 ReferenceError: Can't find variable: jQuery [===============> ] 25% [================> ] 28% [==================> ] 30% [===================> ] 33% [=====================> ] 35% [======================> ] 38% [=========================> ] 42% [===========================> ] 45% [==============================> ] 50% [================================> ] 54% [==================================> ] 58% [========================================> ] 68% [================================================> ] 81% [============================================================] 100% Counting pages (2/6) [============================================================] Object 1 of 1 Resolving links (4/6) [============================================================] Object 1 of 1 Loading headers and footers (5/6) Printing pages (6/6) [> ] Preparing [===============> ] Page 1 of 4 [==============================> ] Page 2 of 4 [=============================================> ] Page 3 of 4 [============================================================] Page 4 of 4 Done

Also notice the ReferenceError: Can't find variable: jQuery in there. This could be the reason my jQuery is not running.

But what is causing it?

2ndmile’s picture

Further Testing...

I had turned on the --debug-javascript option in the Print module settings. After turning it off and outputting a PDF this is what I got.

wkhtmltopdf: Loading pages (1/6) [> ] 0% [======> ] 10% Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file Warning: Blocked access to file [==============> ] 24% [===============> ] 25% [================> ] 27% [=================> ] 29% [==================> ] 31% [====================> ] 34% [=====================> ] 36% [======================> ] 38% [=========================> ] 43% [===========================> ] 45% [==================================> ] 58% [===========================================> ] 72% [============================================================] 100% Counting pages (2/6) [============================================================] Object 1 of 1 Resolving links (4/6) [============================================================] Object 1 of 1 Loading headers and footers (5/6) Printing pages (6/6) [> ] Preparing [===============> ] Page 1 of 4 [==============================> ] Page 2 of 4 [=============================================> ] Page 3 of 4 [============================================================] Page 4 of 4 Done

SO.... Warning: file:///tmp/wktemp-60b5e843-b86e-4f5a-9a9b-900d90efaf4d.html:11 ReferenceError: Can't find variable: jQuery was from the debug-javascript output option.

But I still have the warnings as well.

(Hopefully my thinking out loud will help someone else)

2ndmile’s picture

Further Testing....

Just for my own sanity I put all of jQuery inline and then called my little troubleshooting script and sure enough, the pictures were hidden in the PDF.

Conclusion... wkhtmltopdf can't access jQuery although it will run it when it does have access (in-line test).

Joao, any thoughts on the above warnings?

jcnventura’s picture

Status: Active » Postponed (maintainer needs more info)

Some thoughts yes, but not that I fully understand it.

The core feature of the 6.x-1.11 security patch is to disable local file access in wkhtmltopdf. As wkhtmltopdf runs as the web server user, it can easily be tricked into revealing local stuff if it is allowed to read those files.

What I don't understand is why it thinks that your Javascript is local...

2ndmile’s picture

Status: Postponed (maintainer needs more info) » Active

As a troubleshooting step I commented out line 335 in print_pdf.pages.inc:

//$print_pdf_wkhtmltopdf_options = '--disable-local-file-access '. $print_pdf_wkhtmltopdf_options;

All of the "Warning: Blocked access to file" disappeared but I am still getting the error message from --debug-javascript:

Warning: file:///tmp/wktemp-e0a46771-370b-49d4-8afb-33707906c37c.html:10 ReferenceError: Can't find variable: jQuery

So even though it seems to have access to local files and still can't find jQuery.

2ndmile’s picture

As a temporary workaround I have included a direct call to jQuery and all the relevant jQuery inline in the header of the print_pdf.tpl.php and it is working great, so the problem lies in how the print module is interacting with wkhtmltopdf.

jcnventura’s picture

Status: Active » Fixed

Hi,

I've managed to track it down to the order of the lines in the print.tpl.php.

The following patch fixes it:

--- print.tpl.php       13 Jul 2010 11:04:57 -0000      1.8.2.16
+++ print.tpl.php       18 Aug 2010 00:32:10 -0000
@@ -12,11 +12,11 @@
 <html xmlns="http://www.w3.org/1999/xhtml" lang="<?php print $print['language']; ?>" xml:lang="<?php print $print['language']; ?>">
   <head>
     <?php print $print['head']; ?>
+    <?php print $print['base_href']; ?>
     <title><?php print $print['title']; ?></title>
     <?php print $print['scripts']; ?>
     <?php print $print['sendtoprinter']; ?>
     <?php print $print['robots_meta']; ?>
-    <?php print $print['base_href']; ?>
     <?php print $print['favicon']; ?>
     <?php print $print['css']; ?>
   </head>

I've committed this to CVS

2ndmile’s picture

By Jove, you've got it. Nice catch. Thank you for taking time to figure this one out.

Status: Fixed » Closed (fixed)

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

Rosamunda’s picture

Version: 6.x-1.11 » 6.x-1.12
Status: Closed (fixed) » Active

As I encounter this error again in latest stable version, should I reopen this issue?
I´ve opened another one explaining the problem...

Rosamunda’s picture

I´ve posted the problem in detail, and the solution that I´ve found here.

I´m keeping this open because I think that #8 solution should comment this line: <?php //print $print['base_href']; ?> inside <head>.
After changing my template according to #8 the problem didn´t got solved. It only worked commenting that line, so maybe someone else should check that out and see if it should get commited or not.

Cheers,
Rosamunda

jcnventura’s picture

Status: Active » Closed (fixed)

Opening two issues doesn't help at all in having a 6.x-1.13 release...