We updated the cms from V443 to V445 and found the following errors and solutions and I thought I'd post them here to help out everyone (not sure where to post this as the forum is closed).
_You will need to update two or three things._
If you have bleeding updates turned on and turn to update from V443 to V445 you will come across this error message:

To fix this edit the file found at:
/public_html/modules/backend/database/migrations/2013_10_01_000001_Db_Backend_Users.php
Add the following code:
$table->timestamp('deleted_at')->nullable();
After the line:
$table->timestamps();
Next you need to update the database and add the missing row into the database table.
Open up your database, for me it was cPanel > phpMyAdmin
Find the Table called: backend_users open it and go to SQL and add the line of code:
ALTER TABLE backend_users ADD COLUMN deleted_at TIMESTAMP NULL AFTER created_at;
Now go back into the admin backend and update the cms via settings and should work or command line etc.
Lastly, (and I think many people will not spot this!)
October has updated the |media twig.
So for us we had the following twig code:
https://www.example.com{{ 'image.jpg'|media }}
V443 or below will output this:
https://www.example.com/storage/app/media/image.jpg
V445 now gives the following image URL:
https://www.example.com/https://www.example.com/storage/app/media/image.jpg
So make sure to re-write your twig if you have done this into this:
{{ 'image.jpg'|media }}
That's everything we did to update the cms.
Hope it helps people out.
@ayumihamsaki that first error shouldn't be happening, it should be handled by https://github.com/octobercms/october/blob/develop/modules/backend/database/migrations/2018_12_16_000011_Db_Backend_Add_Deleted_At.php. Could you do some testing (@w20k perhaps you can dig into this to) and figure out why that migration didn't run in your case?
Had that error on some updates and even on a fresh install. Will run some tests...
Thanks. It's definitely something that shouldn't be happening and should be fixed, but we need to know what's causing the issue because in theory it should be working fine.
Hi,
when you see error message,
With your phpmyadmin or other tools go to database -> backend_user
and add new field before created_at
call it :: deleted_at
with attributes = timestamp, nul=yes, default=NULL
and then Clic Try again
I noticed when I updated my Composer dependencies via composer update, I had to manually run the migration above via php artisan october:up - I presume that is expected as it hasn't been added to the post-update-cmd scripts.
If you're using Composer for updating October, make sure to run that command instead of modifying the database directly.
@LukeTowers confirmed - Upgrade from 443 to the 445 cause DB error.
For me on PHP 7.0.33 / MySQL 5.6.41 deleted_at field was listed in migration but somehow it wasn't created in database schema on CMS update.
Is it possible that the updated code runs an Auth call using the SoftDeletes trait before the migration was executed?
The exception comes from this call in modules/backend/classes/Controller.php:147
@tobias-kuendig, is right.
After unpacking and before doing migrations, it calls for a User and exits gracefully :)
Hmmm, how can we fix this?
My naive solution would be to patch OctoberRainAuthManager and make all deleted_at checks manually where necessary.
// vendor/october/rain/src/Auth/Manager.php:408
// Look up user (withTrashed)
if ( ! $user = $this->createUserModel()->withTrashed()->find($id)) {
return false;
}
// Perform deleted_at check manually.
if (array_key_exists('deleted_at', $user->getAttributes())
&& $user->deleted_at !== null
&& $user->deleted_at->lt(now())) {
return false;
}
@tobias-kuendig I don't think that would fix it, the problem is the default scope applied by the SoftDelete trait, the AuthManager would already ignore deleted users. The problem is that the scope is looking for a column that doesn't exist until the migrations are run, so perhaps we need to run the migrations before the controller tries to load the user
The scope can be disabled by using withTrashed where appropriate, right?
I guess it's either patching the AuthManager or adding some kind of "pre-migrations" to the update process. I feel like latter might be risky since the auth check is kind of a nice thing to have before any kind of migration is run :sweat_smile:
Edit: I just tested my example patch to the check method from above on build 445 after manually removing the deleted_at column. Navigating around the backend works fine even though the column doesn't exist. I guess as long as the user is logged in this would be sufficient for the update process. The authenticate and findUserByX methods should be updated as well though.
Ah, I see what you did there. That would in theory work.
Perfect, could you submit a PR to the Library repo to fix the issue?
Do you think it's sufficient to only patch the check method of the AuthManager?
@tobias-kuendig what would be the reason for needing this workaround in the other checks? It's only meant to support this case isn't it? If you can think of a good reason to do it in the other places then let me know.
That's true! I guess https://github.com/octobercms/library/pull/367 will do it then.
@w20k @ayumihamsaki @Eoler @willouch could you guys test https://github.com/octobercms/library/pull/367 and see if that solves the problem? I feel like it does, but I just want to double check before getting @daftspunk to release another build
@LukeTowers
I get a BadMethodCallException, see screenshot:

From the line:
if (!$user = $this->createUserModel()->withTrashed()->find($id)) {
@ayumihamsaki You have to be at least on build 444 for the code to work. You cannot put it into an earlier build since the user model doesn't use SoftDeletes yet.
Remember, the workaround is only relevant for this one request between the download of the updated build 444 code and the execution of the migrations.
Ok strange because I did this and it seemed to work and upgrade from V443 to 445:
/*
* Look up user
*/
if (!$user = $this->createUserModel()->find($id)) {
return false;
}
// Perform deleted_at check manually since the relevant migrations
// might not have been run yet during the update to build 444.
// @see https://github.com/octobercms/october/issues/3999
if (array_key_exists('deleted_at', $user->getAttributes())
&& $user->deleted_at !== null
&& $user->deleted_at->lt(now())) {
return false;
}
Thanks @ayumihamsaki your solution worked for us.
After trying to update to 445 and breaking our site, we then had to try a fresh install which then broke again, and is still breaking due to the deleted_at column not being inserted into the backend_users table during the install.
Once we ran your fix above, it all worked perfect.
Thanks again
Hope it helps people out.
Thank you so much. Saved my bacon just now! Some significant updates to a website were required and we couldn't login. Appreciate it ;-)
Most helpful comment
Thanks @ayumihamsaki your solution worked for us.
After trying to update to 445 and breaking our site, we then had to try a fresh install which then broke again, and is still breaking due to the
deleted_atcolumn not being inserted into thebackend_userstable during the install.Once we ran your fix above, it all worked perfect.
Thanks again