No PDF attached if client profile language is not English

Self-Hosted | v4/Legacy
1

I have the latest version (4.4) self hosted, and I noticed that a client that has their language set as French will not get PDF invoice attached when the mail goes out. If I change the client language to English, the PDF does get attached to the email properly.

The error log (when the client is French) contains these two lines:

[2018-04-25 12:41:42] production.ERROR: TypeError: Attempting to change value of a readonly property.  {"context":"JavaScript","user_id":0,"account_id":0,"user_name":"","method":"GET","user_agent":"Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/534.34 (KHTML, like Gecko) Safari/534.34 PhantomJS/2.0.0 (PhantomJsCloud.com/2.0.1)","locale":"fr","ip":"104.197.162.186","count":1,"is_console":"no","is_api":"no","db_server":"mysql","url":"log_error"} []
[2018-04-25 12:41:45] production.ERROR: PhantomJS - Unable to decode https://invoices.mydomain.com/view/xxxxxmycodeobscuredxxxx?phantomjs=true&phantomjs_secret=xxxxxmycodeobscuredxxxx  {"context":"PHP","user_id":1,"account_id":1,"user_name":"Stephen","method":"PUT","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15","locale":"fr","ip":"xxx.xxx.xxx.xxx","count":11,"is_console":"no","is_api":"no","db_server":"mysql","url":"invoices/6"} []
2

I also just tested with local phantomjs installed and had the exact same problem. If the client language is French, no invoice attached to email and two errors. If the client lang is English, PDF is generated and attached without a problem.

3

Do you know if it was working correctly for you before upgrading?

Try this to test it:

  • Change the app language to French on /settings/localization

  • Click the PhantomJS ‘Test’ link on /settings/email_settings

4

I don’t think this was working before the upgrade, so this is probably not a new problem. I will try your test and get back to you, thanks.

5

so, I did your test, and clicking on the Test link after changing localization to French does produce the following error in the logs:

[2018-04-25 13:01:19] production.ERROR: Error: Syntax error, unrecognized expression: select[name='mail[driver]' {"context":"JavaScript","user_id":1,"account_id":1,"user_name":"Stephen","method":"GET","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 
Safari/605.1.15","locale":"fr","ip":"xxx.xxx.xxx.xxx","count":12,"is_console":"no","is_api":"no","db_server":"mysql","url":"log_error"}

This error is NOT produced if I change the localization back to English.

6

Also, not sure if this is related, but I notice that if my client language is set to French, the email templates and the emails they receive are all in English for the body text, the translations are ignored except for the header and button and closing. (even for out of the box defaults where no changes have been made)

7

Hmm… I wouldn’t expect that error, can you try applying this patch to your codebase:

https://github.com/invoiceninja/invoiceninja/commit/87f7218b87ae1df602b4e91686cf583587d1947e

8

Are you using custom email templates?

The app only translates the email if the email templates are set to the default values.

9

Your patch removes the error! (at least on the email settings test). I will try it now on my invoice sending. Thanks!

As for the custom email templates, I only customized one of them. The others (like the reminders) haven’t been touched, does modifying ANY of the templates affect ALL of them?

10

It shouldn’t, I’ll try to reproduce it.

11

Sadly, although your patch fixed the error in email_settings, it did not fix the error when a client language is set to French, I get the exact same two errors noted in the first post. Anything else to try?

12

The “PhantomJS - Unable to decode” error includes a link, what do you see if you try loading in a different browser or while logged out. You should see the raw PDF data.

In the past other users have reported the “Attempting to change value” error, in those cases it was a problem with the design. I’m not sure why the design would fail with one language but not the other.

13

So this is weird, if I paste that url into safari or chrome, it responds with what I assume is a valid pdf/image:

data:application/pdf;base64,JVBERi0xLjMKJf////8KNyAwIG9iago8PAovVHlwZSAvRXh0R1N0YXRlCi9jYSAx…many more characters…I2Ci9Sb290IDIgMCBSCi9JbmZvIDEyIDAgUgo+PgpzdGFydHhyZWYKMjgwMzgKJSVFT

And in further testing, I have traced it to the ‘Bold’ template (and my own template ‘Custom1’ which is based on ‘Bold’). If I select other templates (I tried ‘Clean’ and ‘Modern’), the invoice is attached, even if the client is French. Any idea what might be wrong with ‘Bold’? I would hate to have to redo my entire template all over again, I spent quite a long time on it…

14

That’s helpful to know.

You may want to try removing sections of the custom design to figure out which part is failing. If you can pinpoint it to a single line it will be easier for me to help.

15

Ok, I found the line causing the problem:

"table": {
          "body": "$invoiceDetails"
        },

if I replace “body”: “$invoiceDetails” with something like:

"body": [
            [
              "Column 1",
              "Column 2",
              "Column 3"
            ],
            [
              "One value goes here",
              "Another one here",
              "OK?"
            ]
          ]

It works just fine. So there is something in the localization/translation of that variable that the system does not like. Any idea where I can find the code for that?

16

SORRY, I spoke too soon, it was some other variable or combo of vars…trying to find it now

17

I think I was finally able to trace it to just one variable:
"text": "$yourInvoiceLabelUC"

If I remove that, it works and attaches the PDF. If it is present, it fails.

18

And I now have a solution in my templates. I substituted "$invoiceToLabel" for "$yourInvoiceLabelUC" and it works for me.

Still have the problem of language templates not sending though…

19

And FYI there is no problem using UC, as $invoiceToLabelUC also works (and $yourInvoiceLabel does NOT). So there is really a problem with that item for some reason (at least in my installation).

20

Thanks for the details! I’ll let you know what I find.