after migration J3 -> J6: all events missing in frontend

Hekla,

I guess that you see that there is an inconsistency in the JEM 4.5.0 upgrade process.JEM 4.5.0 currently allows an upgrade from JEM 2.3.6 because script.php does not define a minimum supported JEM version.However, JEM 4.5.0 no longer contains the complete legacy SQL migration chain.

JEM 4.4.2 contains:

2.3.13.sql
2.3.14.sql
2.3.15.sql
2.3.16.sql
2.3.17.sql
4.0b2.sql
4.0b4.sql
4.1.0.sql onwards

JEM 4.5.0 starts at:

4.1.0.sqlSo the 4.5.0 package should be fixed using one of these two approaches:


OPTION 1 - Support upgrades from JEM 2.3.6

Restore the missing SQL migration files from JEM 4.4.2 into:admin/sql/updates/mysql/The missing files are:2.3.13.sql
2.3.14.sql
2.3.15.sql
2.3.16.sql
2.3.17.sql
4.0b2.sql
4.0b4.sql

This restores the complete migration chain from JEM 2.3.x through JEM 4.x to JEM 4.5.0 (this needs testing).

After adding them, we should test a real JEM 2.3.6 database -> JEM 4.5.0 upgrade and verify the resulting database schema, events, categories, event/category relations, venues, registrations and frontend views.Ideally, the resulting database schema should also be compared with a clean JEM 4.5.0 installation.


 OPTION 2 - Do not support direct upgrades from JEM 2.3.x

If those legacy SQL files were intentionally removed from JEM 4.5.0, script.php should be modified to define and check a minimum supported JEM version in preflight().

Modify preflight() to check $this->oldRelease before allowing the update.

Conceptually:

if ($type === 'update') {
    $this->oldRelease = $this->getParam('version');

    $minJemVersion = 'X.X.X';

    if (version_compare($this->oldRelease, $minJemVersion, 'lt')) {
        $app->enqueueMessage(
            Text::sprintf(
                'COM_JEM_PREFLIGHT_UNSUPPORTED_UPGRADE',
                $this->oldRelease,
                $this->newRelease,
                $minJemVersion
            ),
            'error'
        );

        return false;
    }
}

Add the corresponding language string, for example:

COM_JEM_PREFLIGHT_UNSUPPORTED_UPGRADE="Direct upgrade from JEM %1$s to JEM %2$s is not supported. Please upgrade to JEM %3$s or a later supported version first."

The exact value of $minJemVersion must be determined from the database migration chain and tested. It should not simply be assumed to be 4.1.0 because 4.1.0.sql is the first SQL file present in the package.

If the installed JEM version is older than the minimum supported version, the installer should abort the upgrade and display something like:"Direct upgrade from JEM 2.3.x to JEM 4.5.0 is not supported. Please upgrade to a supported JEM 4.x version first."The exact minimum version should be checked before hard-coding it.

We shouldn't assume that it is 4.1.0 only because 4.1.0.sql is the first SQL update file included in JEM 4.5.0.If the old SQL files are still valid with the final 4.5.0 schema,

I think Option 1 would be preferable because it preserves the historical migration path from JEM 2.3.6.

Otherwise, Option 2 should be implemented so JEM 4.5.0 cannot silently accept an upgrade path that it cannot fully migrate.

What option do you prefer? Can you change the JEM 4.5.0 package?

Thank you McKillo for your investigation.
I already deleted the previous update installation and start now clean from the origin with J3 and JEM 2.3.6.

Did I understand the process correctly?

• I update to J4
• From JEM 4.4.2 I copy the files 2.3.13.sql, 2.3.14.sql, 2.3.15.sql, 2.3.16.sql, 2.3.17.sql, 4.0b2.sql, 4.0b4.sql from com_jem/admin/sql/updates/mysql to JEM 4.5.0
• I update to the modified JEM 4.5.0
• I update to J5
  I update to JEM 5.0.1
• I update to J6

correct?