I will be turning off the auto-update script I think as each time it updates there are starting to be more issues. The original major one was the loss of being able to produce PDF reports at months end.
Now this most important one is 3 different customers reporting PDF e-mailed invoices to them that they cannot open as PDF readers report the documents are ‘corrupted’.
I had a quick look at logged issues but can’t see this one.
Can I downgrade to a ‘safe’ version as I don’t need a lot of the features - all I actually need is less ‘bleeding edge’ setup as I now use your setup to export information into my own custom written accounting tracking web setup for our accountant and ATO, I can’t afford for changes to constantly affect my backend setup and most importantly people being able open what I invoice them.
I haven’t changed anything, it just started doing this by itself since the update.
I can download them in Invoice Ninja and save them as PDFs, then attach them and send them through Thunderbird, but this kind of defeats the purpose of having a web based invoice system.
Which version did you upgrade from?
To test server side PDF generation you need to use the ‘test’ link on Settings > Email Settings. Do you see any new errors on /errors after testing it?
Thanks for the reply. The ‘Test’ link shows:
Error
Failed to load PDF document.
I have the recommended auto-update script in place so whatever was updated previously is the version before this one that the script determines. Only been a problem since 4.5.16 update. I don’t do anything with the config, I just use Invoice Ninja, so it can only be the update that has changed this.
I have an old re-compiled utility called ‘synonym’ which is an ‘ancient’ Linux utility that hooks as a ‘milter’ (Mail Filter) to SendMail, that automatically CCs my sent mail to an internal user that I have ‘procmailrc’ rules set for to automatically ‘record’ the e-mails in current YYYYMM folders - so today’s failed e-mail does have the failed PDF attached which I cannot determine what it is, but it certainly is not a PDF document.
‘file’ command shows file type is ‘data’
vi/vim on the file is just shows a mass of escaped high-bit characters (assuming).
‘od -a’ just shows the file is full of some ASCII characters with the high-bits stripped out - none of it makes sense or contains anything remotely ‘PDF’ in format.
So something got broken somewhere.
Is it possible for me to downgrade to an older release? I only keep the auto-update around in case the PDF reporting gets fixed one day… which has been a very long time now, so my reporting is done by exporting the CSV files for Invoices, Payments and Expenses, and my web script picks up the content and turns it into the info I need via PHP (calling back-end shell scripts) - I run Apache web server.
What change was made in the PDF generation of sending invoices? If I go back into the invoice record itself, I can ‘Download’ the invoice as a PDF, which does work and is how I was able to give the customers actual PDF copies of the invoice, not the jibberish file they received from the sending facility. I love Invoice Ninja and will always self-host my own setup, but if I can’t send PDF invoices to customers, I am better off going back to code things myself using bash with php interfaces to manipulate the stored data. I ran my own invoicing for over 16 years but liked what I saw with Invoice Ninja. Would be a shame to leave it but I
- must
I have looked through the logs under storage and also the /var/log/httpd/* and can’t see anything relating to errors or failures.
You can either overwrite your current install with the previous version or setup a new install with the previous version and migrate over.
https://download.invoiceninja.com/ninja-v4.5.14.zip
Errors are logged to [app folder]/storage/logs/laravel-error.log
Ok thanks for the pointers.
I have disabled auto updates and rsync-ed in the unzip of .14 over the top (as per the update script) and now get a result on the Test link, not sure of its format but at least not an error message now - will see how invoicing goes today.
Whoops, spoke too soon. unzip and rsync of 4.5.14 still produces junk PDF attachments.
What I ‘could’ do for now is download the invoices produced and send them manually until it is hopefully fixed in a future version. I can’t be the only person having this problem?
So I am still in the same boat with no e-mailing of invoices. I can track that on the 20th of November attachment PDFs worked - on the 22nd of November is when the invoices started breaking.
Again, what has changed that would cause this and can it be fixed.
Again, I can’t be the only user having this issue with e-mailing invoices?
There are no actual errors in the logs for IN or Apache.
Sorry, I’m not sure.
I’m not aware of any other users reporting issues specific to the latest version of the app.
Does the times I suggest coincide with the issue I now have?
Also, I just did an overwrite of the existing directory (/u/www/ninja) with the unzip of 4.5.14. Should I have removed things first and if so is there a clear set of instructions to what to preserve and what to remove for such a task - I just assumed it would replace things but perhaps it is preserving something in the directory structure that even though it is .14 in display, bits of .16 are still there?
What do I lose if I set things up from scratch to get the e-mails working again? I can leave the MySQL database as is but I also use expenses with PDF documents to match them - I ‘can’t’ lose those.
Still, was all working my end until the 22nd and then e-mailing invoices produced corrupted attachments.
More testing today.
Installed 4.5.14 - from scratch - copied back ‘storage’ and copied back the .env file - works fine all except sending invoices show as rubbish attachments as originally reported.
Updated CentOS and rebooted.
Same issue.
What under ‘storage’ could affect this? Or can something in MySQL do this?
Given I can ‘download’ the invoices as PDF documents and they are correct, is the conversion to PDF for attachments and downloading an invoice from the same code source - again, is it under ‘storage’ somewhere?
The only common things now with the fresh install and the older setup is .env (hasn’t changed forever), storage (TBA by you guys what changes).
I just updated to CentOS 7 (7.7.908) now - no change.
What should I be looking for to give you for more information on my issue?
Just out of curiosity, are you using PhantomJS Cloud, or a local binary?
Not sure but assuming given I am running things on a local Apache server from the downloaded zip files, it will be local binary? Running via the web interface of course - this does show under the tickbox to Attach PDF in Email Settings:
Using local PhantomJS, falling back to phantomjscloud.com
I know updates always reset settings (defaults back to 10 records per screen instead of 100 etc) but could this be it?
I am out of options and I need this to work short of having to write my own web setup again which I really don’t want to as it will lack all the other ‘nice’ bits in Invoice Ninja.
The PDF attached to the invoices are generated by phantomjs, when you download the PDF in the browser it’s being created by the browser (if it works it doesn’t mean the emails will work).
The only way to test the email PDF is using the test link on Settings > Email Settings. If the PDF fails to attach I’d expect there to be an error in storage/logs/laravel-error.log.
Hope this helps…
If you’re using PhantomJS Cloud, it should look like this in your email settings.
I was able to reproduce the error myself by switching back to that from a local binary and get the same “Failed to load PDF document” error as you. I also tried signing up for a free PhantomJS Cloud account, thinking it could be an issue with not having an API key, and got the same result after putting the key into my .env file.
@Hillel, I double checked and when the error happened, there is no corresponding entry in laravel-error.log, so it might not be returning anything that causes Laravel to log an error. But something has definitely changed with PhantomJS Cloud at some point.
@dmc1961, you might want to try switching over to a local binary for PhantomJS (https://phantomjs.org/download.html). Just extract the file and toss the binary someplace convenient (I use /usr/bin) and add the following lines to your .env file:
PHANTOMJS_BIN_PATH=/path/to/binary
PHANTOMJS_SECRET=somerandomstring
You’ll need the second line if you require your clients to input a password to view their invoices. Once you get that in place, it should simply say “Using local PhantomJS” in the settings, with a link to the test page (which should work now).
Thank you - some progress my end. (You know those moments when there is nothing in the logs, no changes you know of, but still nothing works?)
After removing the line:
PHANTOMJS_CLOUD_KEY=a-demo-key-with-low-quota-per-ip-address
It then showed as:
Using local PhantomJS
From inspection it is pointing to /bin/phantomjs as part of the CentOS rpm package and has been there since I first installed the server (since updated no doubt with my ‘yum’ repo update yesterday). So the two lines in my .env remain as:
PHANTOMJS_BIN_PATH=/bin/phantomjs
PHANTOMJS_SECRET=[a long string of alpha-numeric]
I am the only login to the system as this is all internal for me to invoice with.
The Test link still gives the same result (Failed to load PDF) error but at least now we are getting logs in laravel-error.log
When clicking on the Test link, we now get this:
[2019-11-30 23:46:42] production.ERROR: PhantomJS - Invalid response http://invoices.myserver.com/view/cduapmnhhkhjgkkkel1qy0qusigkisyq?phantomjs=true&phantomjs_secret=CHANGED_BY_ME: {“context”:“PHP”,“user_id”:1,“account_id”:1,“user_name”:“David Clark”,“method”:“GET”,“user_agent”:“Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2019.04 Chrome/73.0.0.0 Safari/537.36”,“locale”:“en”,“ip”:“192.168.x.x”,“count”:1,“is_console”:“no”,“is_api”:“no”,“db_server”:“mysql”,“url”:“test_headless”} []
[ I changed the texts is these logs to cover identity for ‘myserver’, ‘phantomjs_secret’ and LAN IP… except for my name, they know that from these conversations 
]
And when I send test invoices I get this error and no attachments with the e-mails at all now (instead of previously getting a junk PDF file):
[2019-12-01 00:21:54] production.ERROR: PhantomJS - Invalid response http://invoices.myserver.com/view/30pxpp0cfc3lumvsf3ys4jdmmakssfij?phantomjs=true&phantomjs_secret=CHANGED_BY_ME: {“context”:“PHP”,“user_id”:1,“account_id”:1,“user_name”:“David Clark”,“method”:“PUT”,“user_agent”:“Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2019.04 Chrome/73.0.0.0 Safari/537.36”,“locale”:“en”,“ip”:“192.168.x.x”,“count”:1,“is_console”:“no”,“is_api”:“no”,“db_server”:“mysql”,“url”:“invoices/405”} []
I also removed the PHANTOM_SECRET line as a test as I am the only user of this private server, I don’t get errors in laravel-error.log but if I do this I also still don’t get PDF attachments. Version of phantomjs package:
phantomjs-2.1.1-1.el7.nux.x86_64
So, some progress at least now logging messages and can only deduce that something in the options/arguments passed to phantomjs is the issue? Version of phantomjs matches the originator’s website?
You might try using one of the pre-compiled binaries on the download page I linked. I had similar issues when I installed PhantomJS through apt, as something in the package was screwy. It might be a similar case in your CentOS install.
Although in my case, even phantomjs -v caused a crash, so at least your install doesn’t do that. Still could be worth it just to rule out any problems with the yum package, however. Also should check and make sure fontconfig is installed as well.
Thank you yes I will try that just in case something is screwed up in the options/arguments, but I am thinking it has to be some change in the code in Invoice Ninja given the problem only seems to have popped up in the current update, which I am now back to.
[root@invoices ninja]# phantomjs -v
2.1.1
[root@invoices ninja]#
and fontconfig and fontconfig-devel are installed as well.
I did a complete yum update yesterday just to make sure all was well with the actual install.
Hoping what I reported might help, otherwise I will just have to do some manual processes to get invoices to customers and hope an updated release fixes things… otherwise, having looked around extensively far alternatives, I will have to write my own shell/php web interface and move to that (I already do this to manipulate the exported reports from Invoice Ninja for accounting purposes)… but I don’t want to leave such an awesome interface that is now an integral part of my daily business.
So trying all tended (different sources of phantomjs as well), I now have e-mails being sent with ‘no’ attachment, so no solution to this issue which seems to have come about in an update somewhere and not fixed even with the last update (4.5.17).
Log entry from invoice test:
[2019-12-06 00:22:02] production.ERROR: PhantomJS - Invalid response http://SUPPRESSED/view/yhwubqt2ah43mg0yypdmferhhhdqiyup?phantomjs=true&phantomjs_secret=SUPPRESSED: {“context”:“PHP”,“user_id”:1,“account_id”:1,“user_name”:“David Clark”,“method”:“PUT”,“user_agent”:“Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2019.04 Chrome/73.0.0.0 Safari/537.36”,“locale”:“en”,“ip”:“SUPPRESSED”,“count”:1,“is_console”:“no”,“is_api”:“no”,“db_server”:“mysql”,“url”:“invoices/408”} []
I also tried completely removing phantomjs and using the cloud link (which it defaults to) and same result except nothing logged in laravel-error.log - e-mails arrive with no attachment.
Will keep doing my manual process of downloading the invoices and then sending them manually, but as I rely so heavily on this kind of interfaces now, will no doubt start writing my own perhaps so I am back to smoother invoicing.
Maybe I should try an earlier release on a different server??? I should then just need to restore the MySQL database and ‘storage’ directory?
Kind of exhausted all I know to do to fix this one as I don’t touch Invoice Ninja’s code
Sorry for the trouble, FWIW I don’t think it’s related to the version of the app. We’ve had a lot of trouble with PhantomJS in general, we plan to replace it in v2.