[3.0] Miscellaneous fixes for the installer and upgrader#9162
[3.0] Miscellaneous fixes for the installer and upgrader#9162Sesquipedalian wants to merge 37 commits into
Conversation
|
So... Test here next??? |
|
On this PR... Results are actually very good. Only a couple minor nits & questions. 2.1 => 3.0:
Install: Ran fine. Only minor nits...
General observations... These are both maybe just me & my system, not sure... Any thoughts would be welcome.
I think the performance is actually a 3.0 thing. I don't see that elsewhere. I think the self-signed cert is a me thing... I see that elsewhere. No matter what I've tried, if I try to force https, I get sslRedirect within the app. And the installer never detects the cert, e.g., the ssl box is grayed out. I hate putzing with certs... |
|
I'd be OK with this going in as-is. Only nits. |
|
I could dive deeper & try 2.0 upgrades if needed. Sound like a plan? |
Hm. That's not good.
Should be an easy fix.
I haven't noticed that in my tests, but I wasn't particularly looking for it either.
Yeah, that's probably just a you thing. Rather than a self-signed certificate, why not just use one from Let's Encrypt? |
Sounds like a great plan! Thanks, @sbulen. 😊 |
Most of my testing is on localhost. Once things progress, I do final testing on a hosted test environment. For a long time, no issues whatsoever, but browsers have been getting more picky over time. For years, a self-signed cert worked perfectly. Until it didn't... For a while there, I had to create my own CA for local use. Now, that is either unsupported, or, I'm doing it wrong... |
2.0 latin1 => 3.0:
php/apache/mysql logs: Nothing upgrader log:
2.0 utf8 => 3.0:
php/apache/mysql logs: Nothing upgrader log:
pg => 3.0:
php/apache/mysql logs: Nothing upgrader log:
MariaDB 11 => 3.0:
php/apache/mysql logs: Nothing upgrader log:
|
Sesquipedalian
force-pushed
the
3.0/upgrader
branch
from
1e36b28 to
727233c
Compare
These two should be fixed in the latest commits. |
Hm. Does the admin_info_files table not exist in the database before the upgrade starts? |
Bleh. Please run it again with this modified version of ./Sources/Maintenance/Migration/v2_1/CustomFieldsPart1.php. It will once again dump a bunch of crap into upgrade.log so I can figure out where things are going wrong. <?php
/**
* Simple Machines Forum (SMF)
*
* @package SMF
* @author Simple Machines https://www.simplemachines.org
* @copyright 2026 Simple Machines and individual contributors
* @license https://www.simplemachines.org/about/smf/license.php BSD
*
* @version 3.0 Alpha 4
*/
declare(strict_types=1);
namespace SMF\Maintenance\Migration\v2_1;
use SMF\Db\DatabaseApi as Db;
use SMF\Db\Schema;
use SMF\Maintenance\Maintenance;
use SMF\Maintenance\Migration\MigrationBase;
class CustomFieldsPart1 extends MigrationBase
{
/*******************
* Public properties
*******************/
/**
*
*/
public string $name = 'Upgrade Custom Fields (Preparing)';
/****************
* Public methods
****************/
/**
*
*/
public function execute(): bool
{
Maintenance::$tool->logProgress(__LINE__, true);
$start = Maintenance::getCurrentStart();
if ($start <= 0) {
$table = new Schema\v2_1\CustomFields();
Maintenance::$tool->logProgress(__LINE__, true);
$table->normalize();
Maintenance::$tool->logProgress(__LINE__, true);
$this->handleTimeout(++$start);
}
if ($start <= 1) {
Maintenance::$tool->logProgress(__LINE__, true);
$table->populate();
Maintenance::$tool->logProgress(__LINE__, true);
$this->handleTimeout(++$start);
}
if ($start <= 2) {
Maintenance::$tool->logProgress(__LINE__, true);
// Add an order value to each existing cust profile field.
$ocf = $this->query(
'SELECT id_field
FROM {db_prefix}custom_fields
WHERE field_order = 0',
);
// We start counting from 5 because we already have the first 5 fields.
$fields_count = 5;
Maintenance::$tool->logProgress(__LINE__, true);
while ($row = Db::$db->fetch_assoc($ocf)) {
++$fields_count;
Maintenance::$tool->logProgress($row['id_field'], true);
$this->query(
'UPDATE {db_prefix}custom_fields
SET field_order = {int:field_count}
WHERE id_field = {int:id_field}',
[
'field_count' => $fields_count,
'id_field' => $row['id_field'],
],
);
}
Db::$db->free_result($ocf);
Maintenance::$tool->logProgress(__LINE__, true);
$this->handleTimeout(++$start);
}
return true;
}
} |
Sesquipedalian
force-pushed
the
3.0/upgrader
branch
2 times, most recently
from
2ab8fe3 to
e9dbf3c
Compare
Yes, the table exists, & the prefix is specified in Settings.php. It's a simple 2.1 install. I suspect the problem here, though, is that somehow the prefix was lost... It's not "admin_info_files", it's "smf_admin_info_files". |
|
Ah, yes. That would likely explain it. I'll take a look when I have time later. |
MariaDB 2.1 => 3.0:Refreshed the code, implemented your tweak above & reattempted the upgrade. It actually got much further... 
php/apache/mysql logs: Nothing upgrader log (bottom):
|
Should be fixed in latest commits.
Should be fixed in latest commits. If not, things might get a lot harder. Ready for another round of testing, @sbulen. 🙂 |
3.0 Install:
2.1 => 3.0:
2.0 latin1 => 3.0:
php/apache/mysql logs: Nothing upgrade.log (bottom):
2.0 utf8 => 3.0:
php/apache/mysql logs: Nothing upgrade.log (bottom):
pg 2.1 => 3.0:
php/apache/mysql logs: Nothing upgrade.log: MariaDB11 2.1 => 3.0:
php/apache/mysql logs: Nothing upgrade.log (bottom):
|
|
Thanks, @sbulen. It's been a while since I have been able to look at this PR again. I appreciate both your help and your patience.
Should be fixed in latest commit.
For diagnostic purposes, please run it again using this modified version of ./Sources/Maintenance/Migration/v2_1/CreateAlerts/php:
For diagnostic purposes, please run it again using this modified version of ./Sources/Maintenance/Migration/v2_1/PostgreSqlSequences.php:
For diagnostic purposes, please run it again using this modified version of ./Sources/Maintenance/Migration/v2_1/CustomFieldsPart1.php: |
|
Suggestion: Maybe we should just keep the debug stuff in there. That will help reduce back & forth. Consider even making it a switch. Can't have too much diagnostic info & options in these upgrades, IMO... 2.0 latin1 => 3.0:
php/apache/mysql logs: Nothing upgrade.log:
2.0 utf8 => 3.0:
php/apache/mysql logs: Nothing upgrade.log:
pg 2.1 => 3.0:
php/apache/mysql logs: Nothing upgrade.log (portion - this went on for days...):
MariaDB11 2.1 => 3.0:Doesn't look like if failed in the same place... Not sure why: Note the weird display - all the debug lines are still on the same line, no line feeds: 
php/apache/mysql logs: Nothing upgrade.log (bottom only): |
|
A clue, not sure how much it helps.... The generic 'Critical Error' errors appear to be on the calls to handleTimeout() within a step. More likely to happen when attempting a restart. Sometimes, it just seems to fall thru to exit... Trace follows... This logic is new to me, but it seems to be checking for json in $_GET, that isn't there? |
|
OK, did some more sleuthing, & have a couple of things to share...
I'm not quite sure what the fix is unless the upgrader can force a hard refresh to ensure new .js files are loaded. I think this is causing all of the CRITICAL errors w/o messages.
...is being rejected in MariaDB. I'm not sure why exactly yet... Maybe a default or a SQL_MODE issue set for the session. Works OK without the quotes, but I see the same behavior in MySQL. Something appears to be making them behave differently at runtime. |
|
That is all very helpful, @sbulen. Thanks! I'll see what I can do about them. |
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Sesquipedalian
force-pushed
the
3.0/upgrader
branch
from
5b91fef to
e6f7272
Compare
That we can deal with later.
Should be fixed in latest commits. |
I suspect that the existing 2.1 install added those background tasks to the queue just before you uploaded the 3.0 files, and then the old files had been replaced before the tasks had been completed. If I am correct about that, then this problem might take some pondering to solve, since there are multiple ways that the following events could play out:
Event 2 could happen before event 3, between events 3 and 4, or after event 4. A solution to one those scenarios is not necessarily a solution to the others.
Should be fixed in latest commits. |
Should be fixed in latest commits. |
🤬 I'm surprised and confused that the IPv6 steps works when the charset is latin1 but not when it is utf8. Can you apply the attached patch on top of the latest commits to this PR, @sbulen, and then try again? We'll want to test both for 2.0 latin1 → 3.0 and for 2.0 utf8 → 3.0. |
3.0 InstallRan clean thru completion! MySQL/php/apache logs: Clean 2.1 => 3.0Ran clean thru completion! MySQL/php/apache logs: Clean 2.0 latin1 => 3.0
MySQL/php/apache logs: Nothing Upgrade.log (bottom):
2.0 utf8 => 3.0
MySQL/php/apache logs: Nothing Upgrade.log (bottom):
|
|
Just to clarify, were those latest results obtained with the inat_aton.patch applied? |
|
Yes! Not sure it got that far, though? If you like I can try to trace what's going on in recurring events... |
|
I'm pretty sure it did get past all the IPv6 stuff. Adding support for recurring events happens in the 2.1 → 3.0 stage. Something else is happening with that error. |
|
Anyway, yes, please do try to trace what happened with the recurring events support. My guess is that the 2.0 → 2.1 phase of the upgrade didn't leave the calendar and/or calendar holidays table in the expected state, and so the 2.1 → 3.0 phase failed. |
IPv6 errors...Mystery solved... These happen when I don't check the upgrader box to clear out the error log... (Sometimes I check that box, sometimes I don't... 😀 I try to mix it up so those options are exercised...) Run via CLI, you get an error:
Looking in the DB, the IP on these records appears to be unspecified (I think they're empty strings). Note the default in 2.0 is a very oddball 16 spaces, e.g., ' '... These particular errors happen to be session errors put out there by PHP (not SMF) invoking the session routine. From years ago, when I first set these test scripts & backups up. Some of these old errors are scheduled tasks errors. On a 2.0 => 2.1 upgrade, these entries are brought over as NULL into 2.1 without error. Recurring Entry errors...OK, so... Run the same thing again, but this time, clearing out the errors first... This is what the final entries in the trace look like... Immediately after a successful calendar update, it exits:
This is the old "fallthrough" problem I had reported much earlier, associated with CRITICAL errors. I don't think we ever got to the bottom of that. It simply exits after the substep check... |
3 participants
Fixes a bunch of stuff that has come up while testing the installer and upgrader.
@sbulen, we can use this PR to do all our testing to get 2.1 → 3.0 and 2.0 -> 3.0 upgrades fully working, as well as deal with any issues in the installer. Then we'll go back to #9120 afterward.
Fixes #9160