[3.0] Misc fixes

[Sesquipedalian]

1. Security fix: uses hash_equals() in SMF\Maintenance\Maintenance::loginAdmin() and SMF\Maintenance\Maintenance::loginWithDatabasePassword() methods.
2. Logs correct info about who ran the upgrader. Previously, we were doing some silly things with loading and unloading User::$me. Not only was that unnecessary, and not only could it produce inaccurate info in the logs under certain circumstances, but it also further complicated the problems with getting the admin's login cookie right by the time the upgrade was complete.
3. Moves SMF\Actions\Login2::validatePasswordFlood() to SMF\Security::validatePasswordFlood().
4. Implements SMF\Security::checkPassword().
5. Fixes bugs with handling login security tokens in the upgrader.
6. Point 5 ultimately led to replacing Maintenance::$context with just plain old Utils::$context. Upon closer inspection, I realized that there was neither any need nor any benefit to having a separate version of $context; it just caused headaches when using other code, such as SecurityToken::create(), that is already designed to work with Utils::$context.

[Sesquipedalian]

Okay, I think I am done messing with this PR.

@sbulen, would you care to test whether it solves the problem of not being logged after the upgrader exits?

[sbulen]

2.1 => 3.0

Fatal error: Uncaught Error: Cannot access uninitialized non-nullable property SMF\User::$username by reference in D:\wamp64\www\van2130\Sources\User.php:807 Stack trace: # 0 [internal function]: SMF\User->$member_name::get() # 1 D:\wamp64\www\van2130\Sources\Utils.php(1539): json_encode(Array, 0, 512) # 2 D:\wamp64\www\van2130\Sources\Services\ErrorHandlerService.php(286): SMF\Utils::jsonEncode(Array) # 3 D:\wamp64\www\van2130\Sources\Services\ErrorHandlerService.php(185): SMF\Services\ErrorHandlerService->log('Cannot access u...', 'general', 'D:/wamp64/www/v...', 807, Array) # 4 D:\wamp64\www\van2130\Sources\ErrorHandler.php(104): SMF\Services\ErrorHandlerService->catch(Object(Error)) # 5 [internal function]: SMF\ErrorHandler::catch(Object(Error)) # 6 {main} thrown in D:\wamp64\www\van2130\Sources\User.php on line 807

• PHP, MySQL, Apache logs: nothing
• Upgrader log: nothing

[Sesquipedalian]

Well, phooey. I must have broken something in my tinkering after I first pushed. I suppose that's what I get for trying to code while sleepy.

[Sesquipedalian]

@sbulen:

1. I've made changes to this PR. Have they fixed the error about uninitialized properties?
2. If so, does this PR solve the problem of not being logged after the upgrader exits?

[sbulen]

2.1 => 3.0

Getting a different WSOD:

Fatal error: Uncaught Error: Call to a member function allowedTo() on array in D:\wamp64\www\van2130\Sources\Maintenance\Maintenance.php:661 Stack trace: 0 D:\wamp64\www\van2130\Sources\Maintenance\Tools\Upgrade.php(819): SMF\Maintenance\Maintenance::loginAdmin('admin_shawnb', Object(SensitiveParameterValue), false) 1 D:\wamp64\www\van2130\Sources\Maintenance\Maintenance.php(294): SMF\Maintenance\Tools\Upgrade->welcomeLogin() 2 D:\wamp64\www\van2130\upgrade.php(24): SMF\Maintenance\Maintenance->execute(2) 3 {main} thrown in D:\wamp64\www\van2130\Sources\Maintenance\Maintenance.php on line 661

PHP error log reflects the above. MySQL & Apache logs clear.

Upgrade.log:

2026-08-08T17:11:08+00:00
Step 1: Login
Making sure SMF can write to "D:\wamp64\www\van2130\Settings.php"... done.
Making sure SMF can write to "D:\wamp64\www\van2130\Settings_bak.php"... done.
Making sure SMF can write to "D:\wamp64\www\van2130/custom_avatar"... done.
Making sure SMF can write to "D:/wamp64/www/van2130/cache/db_last_error.php"... done.

[Sesquipedalian]

That should be fixed now. The cause was just a silly mistake on my part. If you could test again, @sbulen, that would be lovely!

[sbulen]

Note this branch currently has merge conflicts.

[sbulen]

2.0 utf8 => 3.0:

Completed successfully, I think, but got this upon transfer to forum.

Cannot assign null to property SMF\User::$dataset of type SMF\UserDataset

Some nits:

• Most of the upgrader steps just rolled on to the next step... - Continue button ignored ❌
• I had to re-logon, normally I'm just brought to the forum after an upgrade, still logged on ❌
• Upgrade.php deleted properly ✅

Upgrade log(bottom):

+++ Converting "smf8_user_alerts_prefs" to utf8mb4... skipped.
+++ Converting "smf8_user_drafts" to utf8mb4... skipped.
+++ Converting "smf8_user_likes" to utf8mb4... skipped.
Step 6: Cleanup
+++ Cleanup old files... skipped.
+++ Ensure name of Tasks directory is in correct case... skipped.
Step 7: Finalize Upgrade
Saving the following settings in the settings table: smfVersion... done.
Saving the following settings in Settings.php: maintenance, tasksdir, db_character_set, db_mb4, db_last_error, and upgradeData... done.
Upgrade complete!

2.0 MariaDB => 3.0:

Completed successfully, but scores of errors when navigating the newly upgraded forum:

Tried to check an unknown permission: karma_edit.

Some nits:

• Most of the upgrader steps just rolled on to the next step... - Continue button ignored ❌
• I had to re-logon, normally I'm just brought to the forum after an upgrade, still logged on ❌
• Upgrade.php deleted properly ✅

[Sesquipedalian]

• Most of the upgrader steps just rolled on to the next step... - Continue button ignored ❌

I suspect that is due to the incomplete theme changes. Once all that is complete, we'll check this again.

---

2.1 PG => 3.0:

...

+++ Updating obsolete alerts from before RC3... failed with error: "ERROR: syntax error at or near "JOIN"
LINE 2: JOIN smf_attachments AS f
^"

The fix for that is pending in #9524.

---

2.0 latin1 => 3.0:

Completed successfully, I think, but got this upon transfer to forum.

Cannot assign null to property SMF\User::$dataset of type SMF\UserDataset

Was there a backtrace for that?

---

2.0 MariaDB => 3.0:

Completed successfully, but scores of errors when navigating the newly upgraded forum:

Tried to check an unknown permission: karma_edit.

Were there still some old code files kicking around? I'm trying to figure out how you could have wound up with anything in 3.0 asking for the karma_edit permission.

[sbulen]

I think this:

Tried to check an unknown permission: karma_edit.

...is happening when you do NOT check the 'Delete all karma settings and info from the DB' box.

[Sesquipedalian]

I think this:

Tried to check an unknown permission: karma_edit.

...is happening when you do NOT check the 'Delete all karma settings and info from the DB' box.

Ah, yes, I do see now that there are a couple of places where database queries retrieve permissions from the tables and processes them while simply assuming that they are defined in the list of known permissions.

For the karma_edit permission, I've dealt with this by adding it to the permissions list as a hidden permission.

I've also added backward compatibility code that checks for any orphan permissions in the tables and automatically adds them to the list of known permissions. That should cover the case of any custom permissions added by mods that were written for previous versions of SMF.

[sbulen]

OK, the good news is that the karma_edit errors are gone.

Back to this guy:

Not quite sure why this happens occasionally... Possibly related: I seem to get session timeouts after 2-3 minutes.

Backtrace:

It seems to have this set of errors as well:

[sbulen]

And... When I see these errors...

They are often followed up with this several minute later, after Scheduled Tasks are triggered.

I either get these 6 errors, or none...

[Sesquipedalian]

Latest commit should fix the UserDataset errors.

[Sesquipedalian]

The errors in the RemoveTempAttachments task seem to be completely unrelated to the UserDataset errors, despite the correlation you noticed.

The RemoveTempAttachments errors indicate that the value of Config::$modSettings['attachmentUploadDir'] is not valid JSON. We can add code to the task to avoid generating errors in that situation, but the real question is why that setting is broken. What is the value of that setting in your settings table?

[sbulen]

The ones that fail have a simple string, e.g.:

I'm pretty sure all versions of SMF prior to 2.1 would leave attachmentUploadDir as a simple string like this if there were only one entry.

The 2.1 upgrader had to figure that out... When doing attachment processing, it needed to support restarts/reruns - so it might be a string, it might be a json array, it might be a serialized array. Upgrader attachment processing prior to the JSON conversion step had to handle all 3 possibilities.

SMF/other/upgrade_2-1_mysql.sql

Line 434 in d3f84fa

// We may be using multiple attachment directories.

Note in the above code 'currentAttachmentUploadDir' tells you it's navigating an array... It doesn't exist if it's still just a string... If set, you know it must be json or serialized. Quirky...

And leave it in a state where the JSON conversion step could work.

SMF/other/upgrade_2-1_mysql.sql

Line 608 in d3f84fa

// If it's a directory or an array, ensure it is stored as a serialized string (prep for later serial_to_json conversion)

[sbulen]

For a fun romp down memory lane...
#6942 (comment)

[sbulen]

Let me know if you want me to retest now, or if you want to think about the attachment directory...

[sbulen]

Maybe a 2.1 cleanup task that ensures it's ready for the json conversion?

[Sesquipedalian]

There, that should fix the attachments stuff.

1. The AttachmentDirectory migration step is now idempotent (meaning, running the step again won't change anything) and can handle every possible format that the value might have been in before.
2. The RemoveTempAttachments task uses much more robust logic when figuring out the paths to the attachment directories.

Test away, @sbulen!

[sbulen]

2.1 => 3.0:

Upgrader log (bottom):

+++ Adding new settings... done.
+++ Removing karma... skipped.
+++ Fixing dates... done.
+++ Creating login history table... done.
+++ Converting collapsed categories... skipped.
+++ Fixing attachment directory setting... failed with error: "Class "SMF\Maintenance\Migration\v2_1\Maintenance" not found"

This looks like something simple - I'll hold off repeating the other tests for the moment.

[Sesquipedalian]

Derp. Yeah, looks like I forgot a use statement. I'll fix it when I'm back at a computer.