[3.0] Miscellaneous fixes for the installer and upgrader#9162
[3.0] Miscellaneous fixes for the installer and upgrader#9162Sesquipedalian wants to merge 14 commits intoSimpleMachines:release-3.0from
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
from
727233c to
2ab8fe3
Compare
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>
Fixes error when upgrading from SMF 2.0 Signed-off-by: Jon Stovell <jonstovell@gmail.com>
Sesquipedalian
force-pushed
the
3.0/upgrader
branch
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):
|
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.