[6.0] Fix unlocked and possibly uninstalled core plugins for updates

[richard67]

Pull Request for Issue #45816 (Joomla 6 part).

Summary of Changes

On new installations of Joomla 5 or 6 and updates sites of these versions, the following core plugins are not locked like all core extensions should be:

• plg_schemaorg_article
• plg_schemaorg_blogposting
• plg_schemaorg_book
• plg_schemaorg_event
• plg_schemaorg_jobposting
• plg_schemaorg_organization
• plg_schemaorg_person
• plg_schemaorg_recipe
• plg_schemaorg_custom
• plg_system_schemaorg
• plg_task_globalcheckin

This pull request (PR) fixes this when updating to 6.0 by adding new update SQL scripts 6.0.0-2025-08-02.sql .

The same new update SQL script also adds back the plugins to the extensions table with disabled state when updating in case if they have been uninstalled, but only then.

For new installations it will be fixed when my PR #45821 for 5.4-dev has been merged and then merged up into 6.0-dev.

The changes in the base.sql installation SQL scripts of that PR can be merged up to 6.0-dev without any conflict.

The other changes of that PR will be ignored as there are no 5.x update SQL script in 6.0.

Testing Instructions

Update with unlocked plugins being present

Have an installation of 6.0.0-alpha3 or any older 6.0.0-alpha or 5.4.-alpha version.

For the actual result, update that site to the latest 6.0-dev nightly build.

• Custom URL for live update:
  https://update.joomla.org/core/nightlies/next_major_list.xml
• Update package download for upload & update:
  https://developer.joomla.org/nightlies/Joomla_6.0.0-alpha4-dev-Development-Update_Package.zip

But you can skip the test of the actual result as we already know it has the issue.

For the expected result, update that 6.0.0-alpha3 or older 6.0.0-alpha or 5.4.-alpha site to the custom update URL or the patched update package created by Drone for this PR.

• Custom URL for live update:
  https://artifacts.joomla.org/drone/joomla/joomla-cms/6.0-dev/45822/downloads/86706/pr_list.xml
• Update package download for upload & update:
  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

Then check with a database client like e.g. phpMyAdmin for extensions which are not locked:

SELECT `type`, `name` FROM `#__extensions` WHERE `locked` <> 1;

On a clean new installation there should not be any non-core extensions.

On a real site, only non-core extensions should be listed.

Update with unlocked plugins having been uninstalled

Same procedure as the previous update test, but this time uninstall some or all of the plugins before doing the update.

Actual result BEFORE applying this Pull Request

See issue #45816 and list of plugins at the top of the description of this PR.

The plugins can be uninstalled.

Expected result AFTER applying this Pull Request

No unlocked core extensions can be found.

If the plugins handled by this PR have been uninstalled before the update, they are added back again with disabled state with the update.

Link to documentations

Please select:

• Documentation link for docs.joomla.org:

• No documentation changes for docs.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

[ceford]

I have tested this item ✅ successfully on 2ff9824

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[dautrich]

I have tested this item ✅ successfully on 2ff9824

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[richard67]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[brianteeman]

I have tested this item 🔴 unsuccessfully on 2ff9824

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[brianteeman]

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

[richard67]

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

[brianteeman]

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

[richard67]

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.

[brianteeman]

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

[richard67]

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

[brianteeman]

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

[richard67]

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.

[brianteeman]

/** 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

[richard67]

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.

[richard67]

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.

[richard67]

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

[richard67]

Done.

[brianteeman]

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.

[richard67]

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.

[brianteeman]

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

[richard67]

I posted the log

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

[richard67]

@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

[brianteeman]

I have tested this item ✅ successfully on 23933d5

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[brianteeman]

@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

[richard67]

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

[brianteeman]

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

[dautrich]

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.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[dautrich]

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

[brianteeman]

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

[richard67]

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

[dautrich]

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

But it was necessary in my test.

[richard67]

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

[dautrich]

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

[dautrich]

I have tested this item ✅ successfully on 23933d5

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[dautrich]

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

[richard67]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.}

[richard67]

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.

[dautrich]

I'm gioing to test this one tonight .

[softforge]

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