Good spot. Thank you

I can pick this up if nobody is working on it yet.
From the description it looks like the problem comes from administrator/components/com_admin/sql/updates/mysql/6.1.0-2026-01-29.sql inserting into _content_types with a hard-coded id = 14, which can already be used by WebLinks or 3rd-party extensions.

My plan would be to change the update script so it doesn’t rely on a fixed id for the new core content type (let the table’s auto-increment handle the primary key, while keeping the type_alias/type_title etc. unique), and make sure the corresponding insert for other database types (e.g. PostgreSQL) is adjusted the same way. I’ll also test the update both on a clean 6.1 install and on one with extra content types present (e.g. WebLinks) to confirm there’s no duplicate key error.

Please let me know if someone is already preparing a fix or if there is a preferred convention for core content type IDs that I should follow.

This was also reported in the Joomla! forum.de.
Perhaps the screenshot will help and can be opened.

At the moment problem with the image. sorry.

I can pick this up if nobody is working on it yet. From the description it looks like the problem comes from administrator/components/com_admin/sql/updates/mysql/6.1.0-2026-01-29.sql inserting into _content_types with a hard-coded id = 14, which can already be used by WebLinks or 3rd-party extensions.

My plan would be to change the update script so it doesn’t rely on a fixed id for the new core content type (let the table’s auto-increment handle the primary key, while keeping the type_alias/type_title etc. unique), and make sure the corresponding insert for other database types (e.g. PostgreSQL) is adjusted the same way. I’ll also test the update both on a clean 6.1 install and on one with extra content types present (e.g. WebLinks) to confirm there’s no duplicate key error.

Please let me know if someone is already preparing a fix or if there is a preferred convention for core content type IDs that I should follow.

@Harsh63870 In general you are right, but it would not be sufficient to change the existing "6.1.0-2026-01-29.sql" scripts (for mysql and also for postgresql), as that would not fix any 6.1.0-beta2 or earlier 6.1.0-beta or -alpha version. It would need to comment out the statement in the existing script and provide a new one with the right schema version in its name which inserts the record without the hard-coded id, but only if the record does not exist yet.

As our database updates can be a tricky thing, I would prefer to do that.

@ChristineWk The database issue shown in your screenshot of the database check is expected as the update failed with the previous script, so this one did not run.

I have been testing this on a local laragn env j6.1-dev.

I can confirm that manually inserting a record at ID 14 - simulating a 3rd-party extension causes the update script to fatally crash with SQL Error (1062): Duplicate entry '14' for key 'PRIMARY'.

also I tried removing the hardcoded type_id and the 14 value from the INSERT statement allows the database to correctly auto-increment to the next available ID (in my case, it jumped to 10,000 and so on - maybe due to a previous failed insert attempt) but it worked.

I agree with @richard67 that a defensive script is the way to handle this for existing 6.1 installs.

Thanks for the explanation, @richard67.
That makes sense regarding the existing 6.1.0 beta/alpha installs and the need for a new schema version plus conditional insert. I’ll leave this one to you and will look for other issues without a PR yet where I can help.

PR is in preparation. Will be ready soon.

PR is ready. See #47361 . Please test all 4 test cases, not only if the issue is fixed.

#47361 merged so i close the issue here