Just like title says, I’m trying to save invoices as PDFs. Whenever I use the Print as PDF option, the output is un-openable (Acrobat says it’s been damaged). When I use the E-Mail PDF option, the output is fine.
On the Invoice page, I’m getting some php warnings:
Notice: Undefined variable: module_sub_panels in /srv/http/suitecrm/include/SubPanel/SubPanelTiles.php on line 402
Warning: array_map(): Expected parameter 2 to be an array, null given in /srv/http/suitecrm/include/SubPanel/SubPanelTiles.php on line 402
My logs are kind of a mess, I’m getting the same error hundreds of times (up to 4 times per second):
Tue Feb 12 15:44:03 2019 [ERROR] Pop error level. Try to remove the error_reporting() function from your code.
but other than that I can’t see anything specific about PDF errors.
Any ideas on getting readable PDFs or on resolving the pop error?
There was a similar issue recently here in the Forums… I don’t remember if it had a solution.
You don’t say your version of SuiteCRM or of PHP…
php = 7.3.2-1
suitecrm = 7.11.1
Is this your own server, or is it shared hosting?
Can you run “composer update” from the root of your SuiteCRM installation? This is to update dependencies, including the PDF engine.
I was able to run composer update.
After restarting the webserver, the problem of corrupted PDFs when using Print as PDF option persists.
Can you please open an Issue on Github with this? I think it’s a bug.
Basically the PHP warning are not relevant, but since they get dumped inside the file contents they end up breaking the PDF file produced…
So I was opening the issue and re-checked the logs, I’ve actually got a bunch of PHP Warnings in my server log, like 20,000 lines of errors from the template parser (/srv/http/suitecrm/modules/AOS_PDF_Templates/templateParser.php), with the last warning being:
PHP Warning: opendir(/srv/http/suitecrm/modules/AOS_PDF_Templates/PDF_Lib/tmp): failed to open dir: No such file or directory in /srv/http/suitecrm/modules/AOS_PDF_Templates/PDF_Lib/mpdf.php on line 7506, referer: http://my_host/suitecrm/index.php?action=ajaxui
mpdf.php is there though:
ls -l /srv/http/suitecrm/modules/AOS_PDF_Templates/PDF_Lib/
-rwxrwxr-x 1 me http 1214 Feb 9 23:37 CHANGELOG.txt
drwxrwsr-x 2 me http 4096 Feb 9 23:37 classes
-rwxrwxr-x 1 me http 5358 Feb 9 23:37 compress.php
-rwxrwxr-x 1 me http 3853 Feb 9 23:37 config_cp.php
-rwxrwxr-x 1 me http 8517 Feb 9 23:37 config_fonts.php
-rwxrwxr-x 1 me http 23494 Feb 9 23:37 config.php
-rwxrwxr-x 1 me http 4834 Feb 9 23:37 CREDITS.txt
drwxrwsr-x 2 me http 4096 Feb 9 23:37 font
-rwxrwxr-x 1 me http 5465 Feb 9 23:37 'FONT INFO.txt'
drwxrwsr-x 2 me http 4096 Feb 9 23:37 graph_cache
-rwxrwxr-x 1 me http 26225 Feb 9 23:37 graph.php
drwxrwsr-x 2 me http 4096 Feb 9 23:37 iccprofiles
drwxrwsr-x 2 me http 4096 Feb 9 23:37 includes
-rwxrwxr-x 1 me http 18009 Feb 9 23:37 LICENSE.txt
-rwxrwxr-x 1 me http 463 Feb 9 23:37 mpdf.css
drwxrwsr-x 3 me http 4096 Feb 9 23:37 mpdfi
-rwxrwxr-x 1 me http 1281512 Feb 9 23:37 mpdf.php
drwxrwsr-x 2 me http 4096 Feb 9 23:37 patterns
-rwxrwxr-x 1 me http 1143 Feb 9 23:37 progbar.css
drwxrwsr-x 2 me http 4096 Feb 12 14:03 ttfontdata
drwxrwsr-x 2 me http 4096 Feb 9 23:37 ttfonts
drwxrwsr-x 2 me http 4096 Feb 9 23:37 utils
I don’t have a tmp directory in suitecrm/modules/AOS_PDF_Templates/PDF_Lib, but I don’t know why it’s not finding mdpf.php, it’s there and everything is read/write/executable from the http group. Is there more troubleshooting I can do here, or should I go ahead and report the issue on github?
Also tried doing
mkdir /srv/http/suitecrm/modules/AOS_PDF_Templates/PDF_Lib/tmp & chmod g+rwx /srv/http/suitecrm/modules/AOS_PDF_Templates/PDF_lib/tmp
but that didn’t fix the issue either.
The bug I was saying should be reported is the one about the PHP warnings appearing inside the PDF file.
There might be others, but I would treat them separately…
I’m a little confused what I should be reporting. Which php warnings are getting dumped inside the PDF?
Sorry, my bad - I thought that’s what you were writing about in your first post (I probably jumped into conclusions because of having recently seen a similar case).
But you can confirm this if you please. Try opening the corrupted PDF in a text editor (like Notepad) and see if starts with PHP Warnings. I think that is the cause for Adobe not recognizing it.
sorry to bump this after so long.
I checked the pdf output in a text editor and there are indeed around 1100 lines of errors preceding the pdf usual content.
I am not sure if this was already solved, but please try upgrading to the latest SuiteCRM and checking again.
I had the same problem, I solved it by preventing PHP to display errors, when printing pdf they show at the beginning of the file that’s why it won’t open.
Confirmed, after changing
display_errors = Off
in php.ini and restarting apache, Print as PDF functions properly. Thanks for the tip!