Forum Replies Created

Viewing 16 posts - 1 through 16 (of 16 total)
  • Author
    Posts

  • dmc1961
    Participant

    Update and mark as solved please.

    Still running 4.5.17 but at some stage on my self-hosted box, I changed to URL access to https (so put the VirtualHost entry into ssl.conf in Apache). All good but still squawks about not trusting the key – I generated a local key – it wants something like letsencrypt no doubt, not necessary as this is my own private server inside my setup and https really isn’t a ‘thing’.
    So I dropped it back to http using a local file (/etc/httpd/conf.d/lo_invoiceninja.conf).
    I noticed a reminder I sent actually sent an attached, valid PDF of the invoice.
    I then tested the Test link in Settings – this worked and showed me the invoice PDF template.
    I then sent live invoices and these attached PDFs are now working.

    I also have full access to “Reports –> Documents ” which I really don’t use (I might now though) but this too stopped working some time back – most likely when I did the https change.

    So still an issue with https somewhere but not an issue for me or into the future.

    Thanks for the help, suggestions and patience – back to normal my end.


    dmc1961
    Participant

    Thank you. I will stick with it all for now and will work around the fact I can’t send invoices directly. I will stop outbound e-mails leaving my invoices VM server and download them manually to an ‘automated’ directory area and have a script send them instead. With Linux there is always a way to code around everything in shell 🙂


    dmc1961
    Participant

    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 🙂

    • This reply was modified 4 months ago by  dmc1961.

    dmc1961
    Participant

    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.

    [[email protected] ninja]# phantomjs -v
    2.1.1
    [[email protected] 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.


    dmc1961
    Participant

    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?


    dmc1961
    Participant

    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.


    dmc1961
    Participant

    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?


    dmc1961
    Participant

    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.

    • This reply was modified 4 months, 1 week ago by  dmc1961.
    • This reply was modified 4 months, 1 week ago by  dmc1961.

    dmc1961
    Participant

    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.

    • This reply was modified 4 months, 1 week ago by  dmc1961.

    dmc1961
    Participant

    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?


    dmc1961
    Participant

    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.


    dmc1961
    Participant

    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

    have stability if this system updates automatically.

    I have looked through the logs under storage and also the /var/log/httpd/* and can’t see anything relating to errors or failures.


    dmc1961
    Participant

    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.

    in reply to: Report: Export PDF -> Error: This site can’t be reached #19717

    dmc1961
    Participant

    Please note this issue persists with version 4.5.10 which I see auto-updated the other day. Please let me know what info or adjustments I need to do if you believe this should be fixed. I have made no further changes to my setup since reporting this issue, just left the automated update script running.
    Many thanks in advance.

    in reply to: Report: Export PDF -> Error: This site can’t be reached #18857

    dmc1961
    Participant

    4.5.9 as per the provided update script. Not sure if downgrading is easy/recommended but thinking maybe I try this if month-end February reports still fail on PDFs.

    in reply to: Report: Export PDF -> Error: This site can’t be reached #18851

    dmc1961
    Participant

    Throwing my issue into the ring, being the same one, when trying to export as PDF I get the error reported that ‘reports’ on the local server’s IP does not exist (I am self-hosted).
    Worked last month-end in doing reports but this month the lovely recommended auto-upgrade script I put in place has come back to bite me.
    There are no errors that produce in Apache itself but the internal ‘stacktrace.log’ shows 76 lines starting with:

    2019-02-01 12:22:28 A non-numeric value encountered: #0 /u/www/ninja/vendor/dompdf/dompdf/include/table_cell_frame_reflower.cls.php(103): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, ‘A non-numeric v…’, ‘/u/www/ninja/ve…’, 103, Array)
    #1 /u/www/ninja/vendor/dompdf/dompdf/include/frame_decorator.cls.php(711): Table_Cell_Frame_Reflower->reflow(NULL)
    #2 /u/www/ninja/vendor/dompdf/dompdf/include/table_row_frame_reflower.cls.php(40): Frame_Decorator->reflow()

    FYI:
    CentOS 7.6.1810 (Core)
    mariadb-libs-5.5.60-1.el7_5.x86_64
    mariadb-5.5.60-1.el7_5.x86_64
    mariadb-server-5.5.60-1.el7_5.x86_64
    with php71 but also some php71w packages

    I think I did the “php71w” release as a work-around at some point, but has run like this for over a year now….. till today.

    Everything else is running perfectly so until this is fixed I can’t really get legible PDF docs as part of my company tax reporting responsibilities (CSVs are great but love having both sitting there ready for the accounts or myself in the future).

    I am ‘old school’ I.T/UNIX since 1987 so may go back to my ‘get it all working, don’t change anything afterwards’ approach.

Viewing 16 posts - 1 through 16 (of 16 total)

Posted in: