[#45822] - [6.0] Fix unlocked and possibly uninstalled core plugins for updates
- Pending
- Medium
- Build: 6.0-dev
- # 45822
- Diff
- richard67:6.0-dev-fix-unlocked-core-extensions-2025-08-02
User tests: Successful: Unsuccessful:
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/86585/pr_list.xml - Update package download for upload & update:
https://artifacts.joomla.org/drone/joomla/joomla-cms/6.0-dev/45822/downloads/86585/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
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql |
| Title |
|
||||||
| Title |
|
||||||
| Title |
|
||||||
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.
| Status | Pending | ⇒ | Ready to Commit |
| Labels |
Added:
bug
PR-6.0-dev
|
||
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.
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.
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
- If extensions table does not have a record then it adds the record
- 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.
| Labels |
Added:
RTC
RMDQ
|
||
| Status | Ready to Commit | ⇒ | Pending |
Back to pending as the PR has received changes.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45822.
@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.
| Title |
|
||||||
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.
| Labels |
Removed:
RTC
RMDQ
|
||
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.