Its missing sql to add it to the extensions and assets tables

Its missing sql to add it to the extensions and assets tables on update

Its missing sql to add it to the extensions and assets tables on update

@brianteeman Assets table we never insert on updates and leave that to the asset being created when the settings are saved. But with the extensions table you are right.

Its missing sql to add it to the extensions and assets tables on update

@brianteeman Assets table we never insert on updates and leave that to the asset being created when the settings are saved. But with the extensions table you are right.

Doesnt that lead to missing assets

Its missing sql to add it to the extensions and assets tables on update

@brianteeman Assets table we never insert on updates and leave that to the asset being created when the settings are saved. But with the extensions table you are right.

Doesnt that lead to missing assets

@brianteeman Yes, but that's not a problem as modules inherit from the component (part before the first dot in the asset name), so when you have no asset and now edit the module settings and save, the asset will be created exactly in that way. So when we added modules in update SQL scripts in past, we always added the extension record with asset id zero to the extensions table.

@alikon In the update SQL script we should insert things only if they don't exist yet. For this you can find some examples if you search for "WHERE NOT EXISTS" in the 5.4-dev branch. This will make sure that the extension and module will not be inserted multiple times when the script runs multiple times, e.g. after a failed update.

Another thing is that if this PR counts as a new feature, it would have to go into 6.1-dev and be modified for checking the J6 and the J7 plugins. But a J7 b/c plugin will come very likely not with 6.4, if ever.

We have to discuss that in the maintainers team.

@alikon - I look forward to testing this - I find this concept/new feature a great idea/really useful - thank YOU for taking the time to create it.

This is the sort of thing that a member exception should be made for.

I have tested this item ✅ successfully on bd9d9d3

I have tested this successfully. Once installed, I toggled Backwards Compatibility and Backwards Compatibility 6 plugins to test all combinations!

VERY useful cool little option - thanks @alikon

@alikon Please change the wrong filename 5.4.0.2025-11.08.sql to 5.4.0-2025-11.08.sql (minus instead of dot between version and date) for the MySQL file. The PostgreSQL file is ok.

PS: Ah, I just see the version also needs to be changed to 5.4.2.

@alikon The name of the MySQL update script is still wrong, it contains a dot in the date where there should be a dash.

@alikon See alikon#144 for a proposal for more version agnostic code.

@alikon, I'm retesting this PR but I seem to have found a bug (perhaps one that wasn't there earlier or that I missed can't remember) - either that or I'm going crazy.

With the PR applied, I see the🛡️Backward: 5, 6 message next to the 5.4.2-dev... for whatever reason, instead of going to went to the Plugins page: https://www.domain.com/_j540/administrator/index.php?option=com_plugins&view=plugins, I went to the Manage Extensions page: https://www.domain.com/_j540/administrator/index.php?option=com_installer&view=manage, I pulled up the keyword: Backward and got 3 lines:

Behaviour - Backward Compatibility - Plugin
Behaviour - Backward Compatibility 6 - Plugin
Joomla! Backward Compatibility Information - Module

and here's the RUB, when I clicked on the Status ✅ on Behaviour - Backward Compatibility 6, the menu's 🛡️Backward: 5, 6 stayed the SAME - unless my brain is fried, I would expect it to show: 🛡️Backward: 5, IF I go into the Plugins page and deactivate Behaviour - Backward Compatibility 6 from there, the status changes to 🛡️Backward: 5 as I expect...