This will mean that any j3 site will have to be updated via j4 - is that the intention?

This will mean that any j3 site will have to be updated via j4 - is that the intention?

@brianteeman That's what I assume, and as far as I know that's the plan.

@HLeithner @nibra please correct me if that is wrong.

Just wanted it to be clear. In the absence of any road map its hard to know what the plans are

Yes there will me no direct update path between 3 and 5

In the absence of any road map its hard to know what the plans are

@brianteeman As long as we are not on the road to nowhere ... or the highway to hell ... ?

Depending on the progress we will see if a upgrade to 4.4 is needed (like 3.10) or direct update from any 4.x version is possible.

Depending on the progress we will see if a upgrade to 4.4 is needed (like 3.10) or direct update from any 4.x version is possible.

@HLeithner This depends mainly on if we want to keep the old 4.x update SQL scripts - then we can update from any J4 version - or if we throw them away like we threw away the 3.x update SQL scripts in J4 - then we have to come from the latest J4 version.

@HLeithner P.S.: To throw old update SQL scripts away has the advantage to be more flexible with new update SQL scripts regarding the database checker, because that does not understand when you modify the same thing again in the history of update SQL scripts. E.g. you cannot remove an index and later add it back with the same name, or remove a column and later add it back to the same table with the same same, such things, without the database checker showing false errors which cannot be fixed.

@HLeithner P.S.: To throw old update SQL scripts away has the advantage to be more flexible with new update SQL scripts regarding the database checker, because that does not understand when you modify the same thing again in the history of update SQL scripts. E.g. you cannot remove an index and later add it back with the same name, or remove a column and later add it back to the same table with the same same, such things, without the database checker showing false errors which cannot be fixed.

having a better database management system would also be great^^

I have tested this item ✅ successfully on aa13e59

Works as expected.

We should probably remove the #__utf8_conversion table as part of this PR in this case

We should probably remove the #__utf8_conversion table as part of this PR in this case

@wilsonge The table is already removed (dropped) after a successful conversion here: https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_admin/script.php#L7969-L7974

If the table still exists for some reason in 4.x, the database checker will show that as an error, see https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/src/Schema/ChangeSet.php#L97-L124 .

Using the "Fix" button will then run the conversion, see https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_installer/src/Model/DatabaseModel.php#L305 .

So at the end the table does not exist anymore, or the conversion has failed.

I could add a 5.0.0 update SQL script with a DROP TABLE IF EXISTS ... for MySQL in addition to be sure the table is deleted in any case.

But is that really necessary? If you say yes, I will add the script.

I have tested this item ✅ successfully on aa13e59

RTC (seems nobody else is here who checks if a PR has 2 tests)

thanks

Joomla 4.0 and later require a minimum database version for MySQL or MariaDB which supports utf8mb4 and so would not run on databases which do not support it.

Just FYI this should be the case but the minimum database version is not enforced you can still install and manually update. The Core Updater checks the versions but the CMS itself does not. And we can not enforce this before 5.0 as that would be an unexpected major break while installing an update.