Hi,
I am currently facing a few issues.
A few days ago I set up Invoice Ninja (self hosted) v5.5.82-W110 (shared hosting).
Auto-update issue: Immediately, it informed me that an update was available. However, when I click update, the web page itself refreshes, nothing really happens and the old version continues.
JSON import: Thereafter, I attempted to import my json backup from an earlier v5 version (v5.4.x), which did not throw any errors in my face, but my tasks and payments have not been imported and do not show up.
Company Logo: I went to the settings and uploaded the company logo, but it neither shows in the settings, nor on the top left icon (which just shows blank), nor invoices (which show a broken image link kinda icon), nor client portal (whitelabel). It may be noted that if I try to visit the logo through the relevant web link (https://link.to.ninja/storage/relevant-company-folder/logo-file-name.png), it throws a 403 Forbidden error, but on checking file permissions, I couldn’t find anything amiss (rw-rw-r-- (664)). I found some topics talking about how being behind a proxy could cause issues displaying the logo, so I am clarifying that I am not behind a proxy.
Emails: Emails aren’t being sent out, despite configuring the .env, the email settings on a company level, and assigning it to be sent via postmark. The logs also do not seem to reflect anything, and the Server Logs dashboard column also does not show any failures.
Logs:
When I checked the logs, I could only see this:
[2023-03-12 14:40:03] production.INFO: Missing expense_categories key: (redacted)
[2023-03-12 15:08:53] production.ERROR: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32768 bytes) {"userId":1,"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32768 bytes) at /path-to-invoice-ninja/public_html/vendor/nelexa/zip/src/IO/ZipReader.php:830)
[stacktrace]
#0 {main}
"}
Strange, the system performs a system level check prior to attempting the upgrade so unsure why you just get the refresh, if possible, put the app into debug mode by setting APP_DEBUG=true and then inspect the logs for any errors after reattempting the upgrade.
Was the database modified at all when you created the json backup? the missing expense category key indicates the system could not link the expense to the expense category defined in the model.
This sounds like a permissions issue if the system is unable to upload, with the app in debug mode, please try again, the browser console will provide more information on whether the request was successful.
Can you confirm the .env file is set with QUEUE_CONNECTION=sync quite often on shared platforms, the queues don’t start up, so you may need to move to a sync connection to work around this.
I enabled the setting and did an update once again, and for a really long time it just kept spinning on the same screen and then momentarily threw a “Server Error” before auto-refreshing. Checked the logs to find the same old log issue I mentioned in the original post. For the sake of clarity I am pasting the fresh log below:
[2023-03-18 10:23:15] production.ERROR: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32768 bytes) {"userId":1,"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32768 bytes) at /path/to/ninja/public_html/vendor/nelexa/zip/src/IO/ZipReader.php:830)
[stacktrace]
#0 {main}
"}
(I tried it a second time thereafter, and instead of throwing “Server Error” it threw a “Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32768 bytes)”)
The database was untouched. On the old instance, the expenses, payments and all other features work fine as on date.
The system is definitely able to upload it, considering I am able to manually visit the folder on my hosting server and view and download the file. But I’m not sure which permission is causing the visitors (maybe web server user) to be unable to see the file from the outside. There definitely seems to be some permission issue though, since I am also unable to download json backups generated on this instance.
Yes, I can confirm this. Even the self-test Health Check option on the app says “Email: smtp, Queue: sync”. This issue can now be ignored as I seem to be receiving the “backup generated” emails.
One major issue that I am yet to fix is the recovery of the tasks and payments from my previous instance. I have the .json file, but it doesn’t seem to recover my tasks and payments. My earlier instance died, (hosting expired) so I can’t even export it afresh (in csv or some other format). I do have the file and database backups from the earlier instance, but dropping them into a new server and trying to have them connect does not seem to work for some reason. Is it possible to import the payments and tasks related tables directly from the database from the old instance (v 5.3.71) to the new instance (v 5.5.95)? I am really desperate to get my payment and task logs back, and hope you can help me with it.
One option here is to load the old database up into mysql. Then point your current installation at it and attempt to run
php artisan migrate
or from the browser
/update?secret=
This will attempt to run all of the database migrations to bring your 5.3.71 data up to 5.5.95 once there, you should be able to export your payments / tasks either in the .json format, or via CSV, which can then be reimported into Invoice Ninja.
Hi @david
Thanks for that. The fresh .json export is also unable to import payments and tasks, so that was a bummer.
I successfully exported tasks and payments via .csv, but there appears to be no option to import .csv tasks, which is strange. Am I missing something?
Also, importing the payments via .csv shows that the payments have been imported successfully, but do not reflect in the app at all.
Right, so this would block the rest of the import from importing due to the file missing the expense category id. The only way forward would be to manually edit the backup file and insert the expense category_id that is missing from that file.
If you unzip the file and edit the backup.json file you’ll want to find the expense categories and insert a new object which contains the missing Expense Category, in particular the id field should match the one that is being reported.
You can then repack the zip file (ensuring to maintain the backup folder structure and reattempt the import.
@david
I’m not sure what to look for, and where, in this case.
I have looked at the .json file and was unable to find the “missing key” anywhere, or any key for that matter.
Next, I opened up the database and searched for the same key, and still couldn’t find it anywhere, so am I missing something here?
(If it helps, the missing expense key is not a number, but looks like a hash)
I was going through some other threads trying to figure this out, and in one post one of the developers mentioned that when migrating from one self-hosted instance to another, we should prefer taking a database dump and restoring the instance instead of taking a .json backup (or .csv, etc.).
So as a temporary workaround, since I wasnt getting any positive responses, I went ahead and started using the old database dump that I had.
I do wish this gets resolved soon though, so that there is a more permanent solution to this problem.
