Pdf.min.js issue with 5.3.40

5.3.40 release has given me an error with PDF creation. Traced this to an error in loading the pdf.min.js file. Ninja is adding an erroneous port number to the URL which causes a failure.

The < head > section contains the following line:

<script src="https://myserver.net:80/js/pdf.min.js"></script>
Instead of
<script src="https://myserver.net/js/pdf.min.js"></script>

Note the added :80. This causes an SSL failure as it should not be forcing using port 80. Is there a way of me fixing this so I can issue invoices?

EDIT: same issue with line 12 in < head >

pdfjsLib.GlobalWorkerOptions.workerSrc = "https://myserver.net:80/js/pdf.worker.min.js";




Thanks for reporting this!

cc @david

Can I fix this to be able to produce invoices today?


Are you behind a proxy or something?

Yes, but nothing has changed there. I’ve always run behind a proxy. It seems odd that these calls are being made specifically to Port 80?

I found a long-winded workaround. Injected pdf.min.js (using the correct url without the :80) into the page using the browser console and the pdf was then created. However the download url for the pdf file had the same problem, https but with port 80 required. I was able to copy the link, remove the :80 and download the pdf manually.


More news. Decided to try migrating it via JSON to one of your hosted accounts. That failed because my 18 clients is larger than the 50 allowed! Paid for Pro, tried again. 18 clients now came through, as did expenses and invoices but not the payments. It’s annoying that payments import isn’t supported. Makes it pretty useless to me.

More importantly, the invoice PDF generation doesn’t seem to work on your paid hosted system either! I just get an error message: 500: Internal Server Error - Server Error

EDIT: It all started working! :smile: Payments appeared after about 30 minutes and pdfs now work. If somebody at HQ fixed it, thank you!


Good to hear, one thing you may need to do is also re-upload your company logo

@Mikewood Hey Mike, did you managed to fix the port error issue?

I’ve been fighting with invoiceninja for the past 24 hours. I have the same “hardcoded port” issue. I can make the app run on port 80, no problem. As soon as I enable ssl, everything breaks as some links seem to have :80 “forced” into them.


What doesn’t work: PDFs, can’t upload/view logo, can’t send invoice (probably related to pdf error), customer’s portal (link has :580 forced into it as well). Can’t find anything in the logs although I set the debug parameter. The only error in the system tab is that one:

[Can’t post 2 images per post since I’m new. Yay!] alt: Email–> failure

Expanding it gives an empty grey box I can scroll in for about 30 page.

more details:
When I initially setup the app, I let all config to minimum (ie I used 192.168.X.X:port to reach the app and the URL was set to IP:Port in the docker config as well). Is it possible that a config file and/or database value would have been generated at initial setup, fixing “port 80”, but not updated when running “php artisan optimize”.

If my best best is to redeploy everything and start over from scratch using the “final” values, is there a way to at least export all the config I did (company/customers/invoices)? I’m guessing I could export/import each file?

Emails work as I tried to export clients info and it sends it through e-mail. i did receive the email with the attached csv file. The problem with invoices E-Mail probably has to do with the PDFs not being accessible, which in turn is probably related to the port issue.

can you run HTTPS on port 580?

I’m not following your question here. https “ends” at nginx (proxy manager) afaik.

I stopped the stack I built manually and re-created one from scratch following this guy’s tutorial and did exactly everything he did just for sake of testing. Since his video was promoted on invoice ninja’s website, I thought it’s be a good test. Sadly, couple more hours of fiddling later I ended with the same error.

580 is the external port of the container. I’m guessing somthing “clever” automatically adds the external port of the container to access the link regardless of the URL set in the “env” file?

I have no idea why and how this link is generated.

I switched to unsecure plain http for now so I could send invoices.

Thanks for the upgrade in status.

I’m 99% sure the issue has to do with being proxied at this point. I don’t know how to work around that though. How do you guys do it on your hosted services?

My setup is as follows:
Cloudflare (443) → tunnel → Nginx Proxy Manager (switch to plain http port 580) → Docker host IP:port (580) → docker container (80) → invoice ninja

Additional info:
For nextcloud, I have to set theses variables for links to point at the right protocol since I’m proxied:

  'overwrite.cli.url' => 'https://nextcloud.server.com',
  'overwriteprotocol' => 'https',

Just throwing this here in case theres a similar option in invoiceninja.

NOTE: customer’s portal cannot be accessed either (:580 added to the link).

For future references, adding:

fastcgi_param  HTTPS              1;

In nginx config (nginx-folder/site-confs/default.conf) as stated in this post from 2016:

Fixed the https issue.

Now the only thing not working is the client portal.

Fixed the issue with the client portal. The previous error had cleared up (the port was no longer in the link); it was now an error 500. Scanning the logs (laravel.log) I found that it was trying to read a null value which led me to think it had to do with a user I deleted. I replaced every instance of that user_id in these tables:

And the portal now works. Hope that helps someone someday!