Install InvoiceNinja on Shared Hosting-v5

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.

Hi There:)
I’m facing a similar issue after installing Release v5.2.1 on my shared hosting (hostinger)
They currently offer support for v4xx from the auto install panel. I managed to update my v4 to the latest v4.5.40 in order to get ready to migrate to v5.2.1
I installed invoice ninja 5.2.1 in a subfolder, I changed the info in .env in order to connect to a new DB. When I pont the url to domain/invoiceninja5/ I get 404. Same situation if I point the url to domain/invoiceninja5/public.
According to the documentation, if I install in a subfolder I should change a rewrite rule on .htaccess. It should be updated to RewriteRule ^(.*)$ invoiceninja5/public/$1 [L]
If I apply that change, then I get error 500. I managed to create all the cronjobs described in the ducumentation, but I still facing the same errors.
What surprise me is that if I point the url to domain/invoiceninja5/public/index.php#/ I can log in and use the new version of invoice ninja. I haven’t tried migrating from v4 yet. Any idea why I’m getting error 400???
is it really because my shared hosting doesn’t support proc_open

This is all what I have in my laravel log
cat laravel.log
[2021-06-12 06:17:00] production.INFO: db fails
[2021-06-12 06:50:25] production.INFO: latest version = 5.2.1

@Peter

It sounds like you just need to get the rewrites working correctly.

The system may work without proc_open, I think the self updater needs it.

If you have Softaculous, you can use their one click installer to install Invoice Ninja.

Hi David, thanks for your reply.
My webhosting is not using Cpanel. I have something called Hpanel and something similar to softaculus. However, they only offer invoice ninja 4.5.xx from the auto install option. I did play around with rewrites rules, but I couldn’t make it work and the support people are helpless at the moment.
I managed to install the same version 5.2.1 on my local machine (Ubuntu 20.04 running apache2) and I didn;t have any issues.
I used https://htaccess.madewithlove.be/ to check what .htaccess rules are up to and I discovered that they are getting the redirection wrong.
RewriteRule ^(.*)$ public/$1 [L] is giving this output
The new url is domain/public/invoiceninja5/
The tests are stopped because of the L in your RewriteRule options.
I’ll keep digging to make this work.

[UPDATE]
I did change the rewite rule to RewriteRule ^(.*)$ invoiceninja5/public/ [L] and I got the right URL like domain/invoiceninja5/public/ but this time I got a 404 page from the hosting instead invoice ninja :confused:

If I pont the url to domain/invoiceninja5/public/ I get a 404 from invoice ninja app

Hey there, we can get more verbose log entries in storage/logs/laravel.log if we add a few lines of code to the file app/Utils/SystemHealth.php. Whenever an exception occurs, we make sure some output is printed to the log file by adding info($e->getMessage());. So for example, function simpleDbCheck() would then look like this:

private static function simpleDbCheck(): bool
{
    $result = true;

    try {
        $pdo = DB::connection()->getPdo();
        $result = true;
    } catch (Exception $e) {
        info($e->getMessage());
        $result = false;
    }

    return $result;
}

Hi all. So after moving providers I can finally do the upgrade. The export option is right there - working on that as we speak. Let’s see how painless it is.

  • Update your V4 to the latest version (I used 4.5.50).
  • Setup V5 to a DIFFERENT directory.
  • Use a different SQL database.
  • Ensure credentials are the same as V4.
  • Don’t setup 2FA or anything else (for now).
  • On completion - log in to V4.
  • Go to SETTINGS/ACCOUNT MANAGEMENT.
  • Scroll down to the migration option. Click START MIGRATION.
  • Select “Self Hosted” on the next page.
  • Enter the FULL URL including the /public. So https://mysite.com/ninja/public then hit CONTINUE.
  • Sit back and wait. May take a while depending on your site.

That’s as far as I’ve gotten. I’m sitting and waiting. Once it’s done though - it should be up and running. The only thing I’m wondering about is this…

Let’s say the original site on V4 was mysite.com/ninja/public - if I set up V5 on mysite.com/invoice/public - once I’m done with the migration and everything is working - how do I move V5 from /invoice to /ninja in keeping with the previous naming? What DB settings or files will I need to change to point to the correct directory?

Standing by for any help with that. Once we get that part sorted - I’ll post information with full photos on my blog or wiki (or both) so persons can reference it.

EDIT
Well. That was actually it. Got an email on completion and confirmed that everything is there. Easy enough once the web hosting provider supports V5. Now just waiting on info on how to get information pointed to /ninja.

The idea I have is to reinstall to /ninja and copy the .env from the /invoice directory there. I guess that’s one option. Is there a cleaner way to get it done?

EDIT2
I may leave the link as is with /invoice - but (for science!) would like to know if the method I suggested would work - or if there’s an easier way to get it done.

In addition to renaming the folder you’d also need to update the APP_URL value in the .env file.

Note: if you leave v4 up with different URLs you can forward the v4 links to v5.

1 Like

Will definitely check this out if needs be in future. I’ve already started using the new V5 and I’m trying to catch up to some outstanding stuff. But - as usual - many thanks for the fast response @hillel and keep up the good work!

1 Like