@alikon or @richard67, I did the postgres changes without testing. Can you guys please have a look if they are correct?

You need to check the jaavascript as well. pretty certain that at least the update check uses the eid

You need the IDs in the joomla.sql files because that file is seeding the initial database state which includes several pseudo-foreign key relations to the extensions table. So as long as our initial data seed is entirely a SQL file they need to exist there.

@brianteeman found it in the JS file, on it.

@mbabker I'v replaced the menu and update sites with subselects. So as far as I could see it there are no more hardcoded extension ids.

I did a clean install of this branch
administrator/index.php?option=com_installer&view=update gives
0 Class 'Joomla\Component\Installer\Administrator\Model\ExtensionHelper' not found

Does it include the latest two commits?

administrator/index.php?option=com_installer&view=updatesites
gives

1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 3

administrator/index.php?option=com_joomlaupdate
gives

1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

Can you download it again as there was something missing in the update scripts. You need also to recompile the js files.

@mbabker the package ids are now determined in a second query for the languages.

Can you download it again as there was something missing in the update scripts. You need also to recompile the js files.

no change

Strange, just tested it and it worked. What does the update_sites_extensions table has for content?

What does the update_sites_extensions table has for content?

That was the clue - it was missing the joomla update - rebuilt everything again etc and now those errors have gone

Can you mark as test successful then in the tracker? Thanks for testing!

I have tested this item ✅ successfully on c3560da

So we have two successful tests, setting to RTC.

@laoneo We have merge conflicts though :/

Conflicts fixed

@laoneo I guess we can't merge this fast enough as it has conflicts again :/

@wilsonge let me know if you want to add this (sooner or later we have to). I will fix the conflicts once more.

Let's do this - but please don't touch the update files of the privacy component/action logs stuff per #24188

Ping me when it's done - there's too many PR's for me to track these days so I'm reliant on github notifications/glip I'm afraid :(

Then better to wait till privacy is merged? Because it takes me some time to clean up the merge conflicts, better to do it only once.

works for me

@wilsonge fixed the conflicts. Made a test installation and it worked.

Moved the plugins

Thanks!

Many thanks to @laoneo for this great work.

@laoneo Thank you for this.

At your service :-)

@laoneo Maybe there is still something to be done.

The function getExtensionRecord uses only the name as criteria to get the right extension record, and in several schema updates the element is used as the only criteria, e.g. WHERE element = 'phputf8'. The first method would require that the name is unique for each extension, and the second method requires that the element is unique.

But in the extension table is no unique constraint for any of these columns name or element.

Is that by purpose, or is it just missing?

If just missing: Can we assume that there are never 2 core or 3rd party extensions using the same name, and can we assume the same for the element column? If so, it would just be enough to add unique constraints for those columns in the extension table. I would make a PR for that if desired.

But if it can't be granted that there will never be any extensions using the same name or element, then the criteria for getting the right extension should be extended, e.g. like it is for checking if core extension, where we have columns type, element, folder and client_id, and combination of these can be used to identify the extension, so the mathing criteria to get the 1 extension we want would be e.g. WHERE type = 'library' AND element = 'phputf8' AND folder = '' AND client_id = 0 in schema updates, and the getExtensionRecord would be changed in the same way.

Or maybe a mix of both, e.g. the name column can be assumed to be unique, so we add a uniqoe constraint for it, but the element column can not be assumed to be unique, so we use the condition for columns type, element, folder and client_id mentioned above in the schema updates, or maybe vice versa, i.e. name column not unique, but element comun unique?

I could make a PR for any of the mentioned solutions, but I need feedback if something has to be done and what is the better way.

But like it is now it is not ok, too risky assuming something is unique and not having a unique constraint on it.

Maybe all that was discussed before, but I was missing the discussion because I did not have much time for Joomla in the recent months?

Update: I just see that neither the name nor the element is unique for extensions, like language packs for site and admin having same values for both. So we can't add unique constraints for these columns.

element and folder should be unique i think. Element is unique for everything except plugins. And in the case of plugins element combined with folder is unique.

@wilsonge No, they are not unique, see the update at the end of my comment above.

@wilsonge The schema updates could be ok as long as no third party extensions use element values like 'phputf8' or so, but we could make them 100% safe by using type and element and folder and client_id as criteria. I could make a PR for that.

The name column is not unique. But the new getExtensionRecord functions seems to check only loaded plugins, correct me if that is wrong. So for language extensions which use same name and same element for admin and site clients we could be safe with checking name only because never 2 clients site and admin are loaded at the same time, but I am not sure about 3rd party stuff.

The element determines what folder the app gets placed in. Even if the database doesn’t enforce it I think if you’ll find the existing phputf8 library would get overwritten

@wilsonge For the schema updates, please check PR #24641 .

The extension name and element do not have to be globally unique, they do have to be unique within a set of constraints. #23219 covers some of it.