PDF not generated correctly

Support
21

Did a clean installation in a new directory with a clean DB.
Unfortunately with the same results.

During the installation IP reported all requirements where ok.

Will try installing in a clean machine (Raspberry pi)

22

Did you read that: https://wiki.invoiceplane.com/en/1.5/getting-started/requirements ?

23

Bugger

PHP > 7.0 (PHP 5.6 may not be supported any longer)

Will install 7 and see, what happens.
Thanks.

24

UN-installed php 5.6, Installed php 7.0.26-1

Ran …/setup
unfortunately with the same result.

It appears mpdf can not read the *.css inspite of it being
shown when I use
print_r($html);exit;

I did note that the logo is referenced via the local filesystem whereas the css is via the web

<img src="/var/www/invTest/uploads/WAA_PDF_TestLogo1.jpg" id="invoice-logo">

whereas the css is

<link rel="stylesheet" href="https://...ASERVER.../invTest/assets/invoiceplane/css/templates.css">  
<link rel="stylesheet" href="https://...ASERVER.../invTest/assets/core/css/custom-pdf.css">

I tried the following from the server console

wget https://...ASERVER.../invTest/assets/core/css/custom-pdf.css

It failed!
Confirming that the style sheet is not accessible via https FROM the SERVE ITSELF but is available to external web clients, how can I change the reference to the css to a file system path like the logo.

Regards
Eric

25

PS the server has always served two domains internal/external.

An internal self signed htmls server named ‘zeus.xyz’, and a public name

I assume that some update has changed the ‘context’ under which the mpdf call is being made. so while the web client is being served from the external name the call to fetch the css is being done from the ‘inside network’ using the outside name, resulting in a name resolution error.

Regards
Eric

26

I think this is rather a configuration problem with the web server as mPDF is working for like thousands of installations without any problems.
You could try to completely remove the domain from the CSS link:

<link rel="stylesheet" href="/invTest/assets/invoiceplane/css/templates.css">
27

Thanks for the reply, yes you are correct this should not be required and up to a month ago WAS NOT required.

My solution (proof of concept)

I created a new template from the original
and changed the ‘head’ section as follows.

/application/views/invoice_templates/pdf/ELM-Invoice.php

<head>
    <meta charset="utf-8">
    <title><?php _trans('invoice'); ?></title>
   <style>
   <?php
         include("/var/www/invTest/assets/invoiceplane/css/templates.css");
         echo "";
         include("/var/www/invTest/assets/core/css/custom-pdf.css");
   ?>
   </style>
</head>

Yet to be done:
change paths so that it works as per the
invoice_logo_pdf() method ie paths must not be hard coded, but use IP variables.
can you give me a hint to get.

/var/www/invTest/ (IP variable / PHP)

PS php manual recommends using readfile() as apposed to include() due to security conserns, so I will experiment with that.

PPS I would switch to this method not because it is better, but because it works the same way as invoice_logo_pdf() which means fewer methods are being used in one program therefore less chance of that one out of the blue instances like mine.

Thanks

Eric

28

Final mod looks like this, and has been tested to work in debug and normal modes.
(producing html or pdf views)

<head>
    <meta charset="utf-8">
    <title><?php _trans('invoice'); ?></title>
   <style>
   <?php
         include(getcwd()."/assets/".get_setting('system_theme', 'invoiceplane')."/css/templates.css");
         echo "";
         include(getcwd()."/assets/core/css/custom-pdf.css");
   ?>
   </style>
</head>

Now that the stress is off, I will check the network to see what introduced this error.

Regards
Eric