Update from 3.8.2 to 4.1.2

I’ve done many things so let me post what has gotten me closest:

  1. New server with PHP Version 7.1.13
  2. Created new database and uploaded data.
  3. Copied .env file updating URL
  4. Ran /update
  5. Whoops, Something Went Wrong on /login
  6. Remove /login and it works. Go to invoice/x/edit and “whoops something went wrong”; client/x/edit and “whoops something went wrong”.

Narrowed it down to being the rijindel-128 in my .env. Ran through countless forum posts to run:
hillelcoren commented on Oct 8, 2017
Try the following:
– If there’s a value for APP_KEY in the .env file remove it
– Change the value for APP_CIPHER to AES-256-CBC
– Run: php artisan ninja:update-key

I’ve used the -legacy=true version of the aforementioned as well. Here are some of the laravel errors (not necessarily in this order):
The MAC is invalid.
IV passed is 32 bytes long which is longer than the 16 expected by selected cipher, truncating <- I would imagine this is due to changing APP_CIPHER to AES from rijendel. I delete my key at this point and run the generate key artisan command. Creates a new base64 string.
The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths. <-I presume updating rijindel to AES-xxxxx is the fix for this. Error goes away when I do.

It seem like each error I fix presents a new one… totally fine but that MAC error is a pain. Someone on GitHub had the same thing and there is no solution posted there.

I see several people in these forums that ran the update commands suggested (like the ones above) and they get it to work. I do not. I think /update fails if I leave rijindel-128 in the .env.

And yes, i run the /update after doing most of these steps. I’ve deleted and re-uploaded my database to accommodate for the possibility of a bad update key combo.

Aside from exporting as a JSON (which I prefer not to do since I was once told the schema changes between versions), I’m not sure what to do.

Have you tried running php artisan ninja:update-key --legacy=true without making any changes to the .env file?


Yes and no. I have to change the app URL for the new server, but otherwise yes.

Which yields this:
Function mcrypt_get_iv_size() is deprecated
I know this is okay because you moved away from mcyrpt when Laravel was updated to 5.3 if I recall from my reading.
And I believe the next step was to change the encryption type to AES from rijindel. I’ve read that article.

And I did follow that up with an /update

Are you using PHP 7.1, try 7.0

I thought when it said the minimum version is now PHP 7 that meant PHP 7.1 would work… that’s definitely not something I’m going to undertake on my production server. I’ll have to rebuild something later. Has anyone else ran successfully on 7.1?

Since you’re using an old encryption I think using 7.0 may help to re-encrypt. Once the data is re-encrypted you should be able to use 7.1.

Alternatively you may be able to silence the PHP deprecation warning to make it run on 7.1.

Oh! I thought it was still performing action even though the error was displayed. I didn’t realize it was dying since it seemed like more of a message.

And what exactly needs re-encrypting? I was reading it had to do with the payment gateways and stuff. I don’t really use those things right now so having those reset wouldn’t bother me. I don’t understand why all functionality of modifying payments, invoices, clients revolves around this encryption issue that is related to a payment gateway encryption.

If the online payments feature was used in the past the data exists, it needs to be be re-encrypted otherwise it will be unreadable by the app.

We don’t have a way to reset just this data.

It was never used. Turned on the feature, but no payment was ever made this way. They have all been manual entries.

Have you been able to upgrade?

So… I finally had time to try this today. I used Bitnami on Windows with WAMP stack… php7.0. There is a but involved though. It couldn’t find google_2fa_secret in the database. I presume this is true because it wasn’t in 3.8. I manually added the column and ran it. Then it was successful. I removed the column before running /update for fear of screwing something up. After the /update, it re-added the column.

So yes, 7.0 did work in my test. I was able to do it in like 40 minutes. Part of that was installing bitnami WAMP stack for testing. My production Linux server is on php7.1. Before I move there, is there going to be another problem like this? I burned a lot of time trying to get it work on my production server doing the same thing.

PS C:\Bitnami\wampstack-7.0.27-1\apache2\htdocs\ninja> php artisan ninja:update-key --legacy=true
Thu, 01 Feb 2018 02:24:13 +0000 Running UpdateKey…

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘google_2fa_secret’ in ‘where clause’ (SQL: select * from u sers<code>where</code>google_2fa_secret != )

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘google_2fa_secret’ in ‘where clause’

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘google_2fa_secret’ in ‘where clause’

PS C:\Bitnami\wampstack-7.0.27-1\apache2\htdocs\ninja> php artisan ninja:update-key --legacy=true
Thu, 01 Feb 2018 02:26:03 +0000 Running UpdateKey…
Thu, 01 Feb 2018 02:26:03 +0000 Successfully updated the key, set the cipher in the .env file to AES-256-CBC
PS C:\Bitnami\wampstack-7.0.27-1\apache2\htdocs\ninja>

Can you clarify your question?

From the errors it looks like you tried to run ninja:update-key before upgrading, it needs to be run after upgrading otherwise it will complain about missing fields.

I was answering your last question… if it worked by using php 7.0 instead of 7.1. Then I added additional details on what went wrong upgrading from 3.8.2 to 4.1.4 while using php7.0, but nothing major just a missing column. Please read the full post to understand the original problem.

To be clear, I don’t think you were missing a column. It looks like you tried running ninja:update-key before updating the app.

I did and understood which was not a step I was aware needed to happen. The real response is just on the topic of PHP versions as you asked if it worked. I was getting back to you on it.

Ok, thanks!