I have tested this item ✅ successfully on 2ff9824

I have tested this item ✅ successfully on 2ff9824

RTC

I have tested this item 🔴 unsuccessfully on 2ff9824

Because these can be uninstalled currently I did the following
Uninstalled all the schemaorg plugins
Updated my install using the custom update server for this PR
The plugins are now present but need to be discover/installed (as expected)
Checked the status of the plugins

Expected behaviour that they are locked
Actual behaviour they are not locked

@brianteeman That is neither related to the issue nor to this PR. It is a problem with discovery installation not checking for core extensions and locking them. Nothing which can be done with the SQL scripts.

Its a real world scenario as a consequence of the plugins not being locked originally

P.S. This does not justify a negative test result. The PR fixes what it claims to fix and does not break any existing functionality.

On an update the removed plugins are reinstalled but without the db entries. So the update sql should

1. If extensions table does not have a record then it adds the record
2. If extensions table does have a record then it updates the record

That would be possible, but I am not sure if I want to do that.

On sites where the plugins have already been deleted shouldnt the current update sql have /** CAN FAIL **/;

On sites where the plugins have already been deleted shouldnt the current update sql have /** CAN FAIL **/;

/** CAN FAIL **/ only makes sense when we have a DDL statement which changes structure, e.g. we add a column or an index, and that column or index already exists.

Here we are handling DML statements where we will not get such an error which can be igrnoed.

An UPSERT (or ON CONFLICT clause for PostgreSQL) does not work either because that requires a primary key or unique key to be violated with an insert, only then the update statement will take place, and that does not work here as we have no unique keys on the extensions table and do not use the ID for the insert (which is right).

So the only way out here would be one insert statement for each record with a "WHERE NOT EXISTS" clause.

That would be an overkill maybe.

Nevertheless that can be done with a separate PR.

The same applies for the 5.4-dev PR.

/** CAN FAIL **/ only makes sense when we have a DDL statement which changes structure, e.g. we add a column or an index, and that column or index already exists.

Here we are handling DML statements where we will not get such an error which can be igrnoed.

ah - ok - I misunderstood /** can fail **/

So the only way out here would be one insert statement for each record with a "WHERE NOT EXISTS" clause.

I do think this is the only way to achieve the aim of this PR - to ensure that the schemaorg plugins are locked

So the only way out here would be one insert statement for each record with a "WHERE NOT EXISTS" clause.

I do think this is the only way to achieve the aim of this PR - to ensure that the schemaorg plugins are locked

@brianteeman No, that is already done by my PR (if the plugin is installed). What I wrote is for adding back the plugin to the extensions table when it has uninstalled in the 5.x installation before the update.

P.S.: A more general way to fix the reinstallation thing would be to make the discovery installer check if something is a core extension and set it to locked if yes. In this way the plugins would not be added back by an update SQL, it would still need to use the discovery installation. But it would work for all similar cases in future as long as the Extensions Helper is up to date with the list of core extensions.

Back to pending as the PR has received changes.

@ceford @dautrich @brianteeman Could you test again? The first 2 tests are the same as before, but there is an additional 3rd test with updating when some or all of these plugins have been uninstalled before doing the update. Thanks in advance.

Thanks for the update.

I tested the sql inserts - they work - but do you think these plugins should be disabled. The user had uninstalled them for a reason so I would think it is better that they are re-installed as disabled

I tested the sql inserts - they work - but do you think these plugins should be disabled. The user had uninstalled them for a reason so I would think it is better that they are re-installed as disabled

@brianteeman I will check tomorrow. Done.

manual check of the sql is ok
just tried an update and the sql did changes did not apply - will try again later

@brianteeman I have to update the links to the package and custom update URL created by drone. They are still the old ones.

Done.

tried a few times now

• Clean install of j6 current branch
• uninstall schemaorg plugins
• set update server to https://artifacts.joomla.org/drone/joomla/joomla-cms/6.0-dev/45822/downloads/86706/pr_list.xml
• updated joomla
• plugins are not reinstalled

2025-08-06T09:00:14+00:00	INFO 127.0.0.1	update	Test logging
2025-08-06T09:00:14+00:00	INFO 127.0.0.1	update	Update started by user brian (546). Old version is 6.0.0-alpha4-dev.
2025-08-06T09:00:14+00:00	INFO 127.0.0.1	update	Downloading update file from https://artifacts.joomla.org/drone/joomla/joomla-cms/6.0-dev/45822/downloads/86706/Joomla_6.0.0-alpha4-dev+pr.45822-Development-Update_Package.zip.
2025-08-06T09:00:16+00:00	INFO 127.0.0.1	update	File Joomla_6.0.0-alpha4-dev+pr.45822-Development-Update_Package.zip downloaded.
2025-08-06T09:00:17+00:00	INFO 127.0.0.1	update	Starting installation of new version.
2025-08-06T09:00:41+00:00	INFO 127.0.0.1	update	Finalising installation.
2025-08-06T09:00:41+00:00	INFO 127.0.0.1	update	Start of SQL updates.
2025-08-06T09:00:41+00:00	INFO 127.0.0.1	update	The current database version (schema) is 6.0.0-2025-08-02.
2025-08-06T09:00:41+00:00	INFO 127.0.0.1	update	End of SQL updates.
2025-08-06T09:00:41+00:00	INFO 127.0.0.1	update	Uninstalling extensions
2025-08-06T09:00:41+00:00	INFO 127.0.0.1	update	Deleting removed files and folders.
2025-08-06T09:00:42+00:00	INFO 127.0.0.1	update	Cleaning up after installation.
2025-08-06T09:00:42+00:00	INFO 127.0.0.1	update	Update to version 6.0.0-alpha4-dev+pr.45822 is complete.

tried a few times now

* Clean install of j6 current branch

@brianteeman You mean the current 6.0-dev branch without this PR applied?

Or have you made the new installation with my PR applied?

If the latter, then the schema version in database will already be the one of my new update SQL and so it will not run when updating.

You can check in the update log if it has run or not.

tried a few times now

* Clean install of j6 current branch

@brianteeman You mean the current 6.0-dev branch without this PR applied?

yes

You can check in the update log if it has run or not.

I posted the log

I posted the log

@brianteeman Ah, I missed that. I have to check that later this evening.

@brianteeman And you are 100% sure that the "6.0.0-2025-08-02.sql" file was not present before the update from some previous test?

You can make sure a branch is clean by doing

git clean -d -x -f
git checkout .
composer install
npm ci

I have tested this item ✅ successfully on 23933d5

@brianteeman And you are 100% sure that the "6.0.0-2025-08-02.sql" file was not present before the update from some previous test?

that must have been the problem

@brianteeman Thanks a lot for testing, it's much appreciated. Could you also test the one for 5.4-dev? That would be really cool.

i am doing that one right now. wanted to get this one out of the way first

I have tested this item ✅ successfully on 23933d5

I uninstalled the schema plugins before updating to the drone update. After the update, the plugins were not immediately visible, but needed a discover installation. But I think that is okay.

We might evaluate adding a compatibility note or a postinstallation message similar to that:

"Up to J5.3 it was possible to uninstall the Schema.org plugins, which should not be possible for core extensions. If somebody did this, the update to J5.4 or J6.0 will bring those plugins back. But to use them, it is necessary to do a discover installation."

the entire point of this PR is that you do not have to discover and install - so if that was your experience then it did not work as intended and you have not successfully tested the PR

Yes, it should not need to discover them after the update.

Yes, it should not need to discover them after the update.

But it was necessary in my test.

@dautrich Have you applied the patch of this PR before the update? If so, that was wrong. The patch shall not be applied before the update.

Sorry, I took a wrong update package. I will repeat my test.

I have tested this item ✅ successfully on 23933d5

As you tell around Frankfurt, Germany: "Kaum meschst mer's rischtisch, scho gehts!"

RTC

Thanks @brianteeman and @dautrich for testing. It's really appreciated as it is some work.

@dautrich There is another PR for 5.4 for the same thing.

I'm gioing to test this one tonight .

Big thanks for the work on this and all the back and forth with the testers. Great job