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...

unable to replicate work as expected

I have tested this item ✅ successfully on 717f31d

• Tested using JBT with all the defaults: PHP 8.4.15, MariaDB 10.6.23, Debug System, Error Reporting Maximum, Log Almost Everything
  • graft full package
  • Shows no, Backward 5, Backward 6, Backward 5+6 correctly
    • Different order as in shown expected result, but this doesn't hurt me
    • 
  • No log entries, module 'Backward Compatibility' is correct shown in Administrator modules
• Reinstalled Joomla w/ PostgreSQL 15.8
  • Shows no, Backward 5, Backward 6, Backward 5+6 correctly
    • Different order as in shown expected result, but this doesn't hurt me
    • 
  • No log entries, module 'Backward Compatibility' is correct shown in Administrator modules
• Reinstalled Joomla w/ MySQL 8.1.0
  • Shows no, Backward 5, Backward 6, Backward 5+6 correctly
    • Same (different) order as with MariaDB
  • No log entries, module 'Backward Compatibility' is correct shown in Administrator modules

I have tested this item ✅ successfully on 717f31d

I have successfully tested this PR. (Now it's working perfect ;) ) Thanks @alikon.

RTC

RTC as it has 2 successful human tests ... but as it is a new feature I've also set the RMDQ (release managers decision queue) to flag that it needs a further decision if it shall be merged or be moved to 6.1-dev. We will decide that soon.

In maintainer meeting we discussed this PR and it was decided not to integrate it into 5.4 or at all. The reason for this is that the information may be misleading, the information is irrelevant when the website is working, behavier plugins are checked during the update, and the information for 'Behaviour - Backward Compatibility' plugin, including the settings, is already included in the system information.

Nevertheless, thank you very much to @alikon for contribution, @richard67 for support and @exlemor for testing.

bad decision imho

better if the maintainer can close issues before someone come out with a pr and spend times for nothing