Is it possible you have more than one app install, maybe you need to check the ninja1 folder?
I do have more than one installation. Ninja1 is working fine - that’s v4. It was broken after older PHP 7.x was removed by hosting provider - moved to 7.3 now I believe and while it works - sending emails it gives me an error. But it actually sends. Logs don’t indicate anything new for today or even this month.
In the mean time - going to redo the entire process. Delete the ninja2 directory from the web host and re-upload. I had some prompts with FileZilla asking me to overwrite some files. I find that strange since there shouldn’t be anything there in the first place. Maybe what I’ll do is put it to ninja3 for the time being just to ensure no residual stuff or conflicts of any kind. Going to re-download and start the process in a bit. Will get back to you. I’ll leave ninja2 alone for now and move the new files to ninja3.
EDIT1
So I’ve downloaded v5.1.70-release from Release Release v5.1.70-release · invoiceninja/invoiceninja · GitHub
Extracted and currently uploading to “public_html/ninja3/” since ninja2 was giving issues somewhat. I’ll rename the directory after and point it to my subdomain https://invoice.mysite - since the cPanel allows me to specify PHP versions for the subdomains. Will update on completion of the uploads.
EDIT2
Should I modify the default ENV file? Or leave it for now to try and to get the setup page displayed?
Going to have to go out soon and will not be back for the rest of the day. Will attempt to get things done from my system remotely - about 100MB left to upload now (about 17,000 files).
EDIT3
So I realize there were like 400+ failed transfers. This came up to 403 thus far. I’m going to wait until the rest are done and then re-queue them to see if there are any conflicts. I added them back since the reason was “disconnected from server” and not any conflict that I see. So waiting on that to compelte.
EDIT4
So I’ve come upon the upload error. I’ve set it to overwrite everything. So now waiting on completion again.
OK. So here we go. Upload complete. Navigating to mysite/ninja3 gives this.
Going to mysite/ninja3/public gives the setup page which is at /ninja3/public/setup
So I fill it out.
Completed and it takes me right back to the original setup page. Navigating to mysite/ninja3/public gives this.
I now also have a laravel.log file which has:
[2021-06-03 15:55:15] production.INFO: db fails
[2021-06-03 15:55:17] production.INFO: db fails
[2021-06-03 15:55:17] production.INFO: db fails
[2021-06-03 15:56:44] production.INFO: db fails
[2021-06-03 15:58:54] production.INFO: The Process class relies on proc_open, which is not available on your PHP installation.
[2021-06-03 15:59:12] production.INFO: account table not found
So that’s what I got for now. Hopefully this helps with the troubleshooting process.
If I navigate manually back to mysite/ninja3/public/setup then I get the setup page again. Based on the error I’m going to email the provider and ask about the “proc_open” option.
EDIT
And I heard back.
So apparently, this may not work for me. Is there any other workaround that could be used?
@david - that seems like my path at this time. I still want to try at it though since v4 is working on the same provider.
I’ve enabled error details in the ENV. Here’s the list.
I would dare say the proc_open function is directly related to the app attempting to write the database migrations. Hence the error you are seeing here.
It if it any consolation, there should be a lot of webhosts you can turn too. We have seen the app work perfectly fine on shared hosting!
1 Like
Thanks for the reply. I’m a bit confused as v4 works. Let me do a quick setup of a v4 instance in /ninja4 and test - because I’m assuming that v4 uses the same proc_open right?
EDIT
OK @david and @hillel - I’m officially confused. I’ve successfully setup 4.5.39 into /ninja4. I saw the message at the start saying that proc_open needs to be enabled. It setup and I’m logged in. Used the same database that I setup for v5 and it’s functional. So I’m confused as well as to WHY it broke when I did an upgrade of 4.5.17 to 4.5.39. Anyways - that’s for the v4 thread.
Having successfully setup v4 in another directory - is there anything that you can think of as to why v5 doesn’t work? Is it that v4 uses some workaround if proc_open isn’t available?
In v4 proc_open is only used when updating the app, it explains why a clean install works but an update does not. As a workaround to updated v4 you should be able to copy over the database and .env file to the new v4 install.
Thanks hillel. I’d need some assistance/details on how to do this though. Would it be just a matter of pointing the settings to the old database?
On the v5 side…is there no workaround to installing? Can I edit the ENV and manually drop in the settings to try and get it working? Or will proc_open be a requirement to get it working in the first place? Kinda grasping at straws here. The current hosting provider also has other services that I use. Price point aside - the features they give are better than my previous providers.
If there’s no way through this then I’m going to ask for assistance with finding a provider. I need:
- At least 2 domains (.com/.net).
- Unlimited bandwidth.
- 2FA.
- 50 or more databases (current provider gives 100).
- 200GB+ of storage (current provider gives 250GB).
- 4GB+ RAM (current provider gives 6GB).
- 20+ addon domains (current provider gives 52).
- At least 1,000 subdomains (current provider gives 5k).
- At least 100 allowed processes (current provider gives 300).
- Separate SQL storage of at least 100GB (current provider gives 200GB).
- At least 100 email accounts (current provider gives 5k).
- Unlimited email storage.
- At least 100 FTP accounts (current provider gives 5k).
- Unlimited autoresponders.
- Unlimited email filters.
Not sure if that’s unreasonable. But it’s what I’ve gotten accustomed to. And at under USD$120 per year.
You can either point the new app to your old database (easier) or setup a copy of your database to point to (safer).
1 Like
Hmm. OK. Going to go with easier for now. Change the directory names and check if it works. Let’s cross fingers and see.
Back to v5. If you think of ANYTHING at all let me know please. And thanks again.
EDIT1
Well - that was painless going the easy route with v4. Works like a charm. Gonna rename the directories now and test again.
EDIT2
For persons doing this on v4 - just ensure that the URL in the APPLICATION SETTINGS or I guess in the ENV manually edited after - ensure it points to the new directory or else it won’t allow you into certain areas.
EDIT3
Well now - that failed lol. I can’t edit the invoices.
“implode(): Passing glue string after array is deprecated. Swap the parameters”
Checking something.
That error is usually from using PHP 7.4, changing to 7.3 should resolve the problem
Thanks for that. Going to make a new thread about this and document the process. I got a bit too many errors during checks so may go a longer route to update.
- Couldn’t log in.
- 2FA stopped working.
- Can’t edit invoices.
And since doing it the easy way - I can’t get back into this.
(1/1) ErrorException
implode(): Passing glue string after array is deprecated. Swap the parameters
And when I switch the other one back to ninja4 I’m getting 2FA errors as well.
(1/1) DecryptException
The MAC is invalid.
EDIT1
So for v4 I think I’ll export the JSON and then import that into the new version - setup from scratch and get it done. A preview shows that it imports just about everything. Not sure what’s missing if anything…So yeah.
Back to v5. I’ll watch the thread and hopefully something will pop up. Thanks again for your time guys and thanks for the AWESOME app and support! Keep up the good work!
EDIT2
So what I did to get v4 working was this.
- Rename /ninja to /ninja.old
- Create a new /ninja directory
- Redo the upload of latest v4
- Setup database for latest v4 to match old v4
This worked and gave me back all options - however the 2FA login seemed to be problematic. So I…
- Temporarily renamed /ninja to /ninja5
- Renamed /ninja.old back to /ninja
- Logged in
- Disabled 2FA
This worked and I’m in so far. No issues outside of needing to switch back to PHP 7.3 - after doing so all errors are gone.
I really need to switch this info to a new thread so we don’t confuse the two. Will do so in a while or later/weekend. Thanks again as usual. Let me setup back the 2FA and re-link to phone app.
Once I post a new thread on this I’ll link to it and send details.
EDIT3
Link available. Details posted. Many thanks for the assistance with resolving the v4 issues. Should be able to focus entirely on v5 now going forward.
Still hoping something can be done to at least get it running. I mean - the DB can be accessed as seen from v4. Is there anything that can be done to directly point the information out? I guess I could try putting the information into the ENV again and see if it works - just not sure about the mail details because that seems to be giving trouble for some users. Let me attempt that and post back.
So I’m creating a new post to move forward. Would also like to drag in @apocalips as a question was asked about v5 in one of the previous posts.
AFAIK - once your hosting company supports proc_open it should be a simply extract/upload/setup operation. That’s what I’ve gotten so far from discussions in this thread. Did you get this resolved?
EDIT1
Since I think I’ve gotten the v4 sorted totally (no issues so far) I’m currently creating new v4 and v5 directories on my web server to assist with documenting the process.
I’ll try to do full setups from scratch and add screenshots to my site. I’m still hopeful that we can get v5 installed without proc_open being available - but waiting on something to test.
EDIT2
So…Seems I’m at a dead end and proc_open is absolutely required.
[2021-06-06 12:28:15] production.INFO: The Process class relies on proc_open, which is not available on your PHP installation.
What I did was create a new database entirely and redo the upload from scratch. What it does is go right back to the setup page and the laravel.log under /ninja3/storage/logs shows the quoted info above.
So unless someone gives something to try - I’m going to check around for other hosting companies that may fit the bill.
1 Like
There’s really no play/work around for the proc_open thing huh?
Sorry, not that I’m aware of
Hi @khat17 , thanks for all the work putted in testing. Thanks for your guide on V4 i was able to setup mine.
Also thanks to all the team at InvoiceNinja for the continuous update on the app.
I was on the fence about going thru all the husttle of update my V4 to then try the v5 Migration but reading all you the work you did seems we are in the same boat.
Thinking about it gave me 2 ideas.
The proc_open when is needed?
*Normal operation
*Just Updating/Migration/installing process
on the provider page about php_modules finded this small letter.
-VPS and Dedicated servers are less restrictive when requesting/applying modules.-
Maybe if the proc_open is only needed for the migration/update/install process we can ask the provider for a vps or dedicated server to do the update/migration process then export the database and do a clean install then import the backup from the VPS/DedicServer.
The other option i was thinking was doing all the process in a personal VM machine like this.
-ExportDatabase and Settings from current V4Shared.
- Install new VMServer V4 , import database and settings from V4Shared.
-Install new VMServer V5, import database and settings from V4 VM or V4Shared?.
-Export Database and Settings from VMServer V5.
-Install new V5Shared, import database and settings from V5VMServer.
If this workaround works, maybe for future update we only need to do the last 3 steps but only using V5. So we can have around a VMServer on version sync with V5Shared to just do updates.
Maybe someone with knowledge about local server and V4 to V5 migration can shine a light here.
Greetings
This is an interesting proposition. I’m willing to try, but I only see this working if it’s a few files that can be copied over. Maybe if just the ENV file is needed, the database can be imported to the hosting provider and the ENV edited to point to the new DB.