[#38526] - Freeze loading of plugins on update finalisation
- Closed
- 8 Sep 2022
- Medium
- Build: 4.2-dev
- # 38526
- Diff
- nikosdion:fix/38486-part2-freezing-plugins
User tests: Successful: Unsuccessful:
Replaces gh-38491 (part 2 of splitting that PR)
Pull Request for Issue #38486 .
Summary of Changes
Disable loading all non-core and most core plugins during the task=update.finalise, task=update.cleanup and related helper tasks of com_joomlaupdate to prevent third party plugins which are not compatible with the new version being installed from getting in the way of the update (they would prevent schema update and any post-update and cleanup tasks we need to perform). They are NOT disabled in the database, just not loaded during those tasks.
You will need the System - Sabotage plugin:
plg_system_sabotage.zip
From Joomla 4.0.0
- Install a Joomla 4.0.0 site
- Replace administrator/components/com_joomlaupdate, components/com_joomlaupdate, media/com_joomlaupdate, and administrator/language/en-GB/com_joomlaupdate.* with the files from this PR.
- Log into the backend
- Install the plg_system_sabotage plugin
- Go to Extensions, Manage, Plugins. Enable the System - Sabotage plugin and click on its title.
- Set the sabotage type to Both and the minimum Joomla version to 4.1.9999
- Upgrade the site to Joomla 4.2 using the package built from this PR
- Try to access your site's frontend
- Make sure the
#__user_mfatable exists
From Joomla 4.1.5
- Install a Joomla 4.1.5 site
- Log into the backend
- Install the plg_system_sabotage plugin
- Go to Extensions, Manage, Plugins. Enable the System - Sabotage plugin and click on its title.
- Set the sabotage type to Both and the minimum Joomla version to 4.1.9999
- Upgrade the site to Joomla 4.2 using the package built from this PR
- Try to access your site's frontend
- Make sure the
#__user_mfatable exists
Actual result BEFORE applying this Pull Request
The table is missing
You WILL receive errors once the update is done. That is exactly what the System - Sabotage plugin as configured in the test instructions is meant to do: throw an error with a stanza from Beastie Boys' “Sabotage” on the target Joomla version and any later version. This error got in the way of running the update finalisation which is why the schema update and cleanup did not run. It's a sabotage!
Expected result AFTER applying this Pull Request
The table exists.
You WILL receive errors once the update is done. That is exactly what the System - Sabotage plugin as configured in the test instructions is meant to do: throw an error with a stanza from Beastie Boys' “Sabotage” on the target Joomla version and any later version. HOWEVER, this time around the sabotage plugin did not run during the update finalisation and cleanup. Therefore both the schema update and cleanup ran just fine. It's a mirage!
Documentation Changes Required
None.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_joomlaupdate Libraries |
laoneo
- | Labels |
Added:
?
|
||
@brianteeman Freezing happens throughout specific tasks, namely the update.finalise and update.cleanup and long before we have a logger (it happens in the application pre-initialisation code, otherwise system plugins would already be loaded and the update quite possibly already failed). However, entering these tasks they already produce a log entry which means that we already know when we are executing update code while plugins are frozen.
We don't thaw plugin events. I did not even implement a thaw logic on purpose; if a crash happened thawing plugins at the end of either page load the update would still fail miserably. Quite simply, plugins are NOT frozen in any page load outside the two specific tasks of com_joomlaupdate. I even made sure that the code cannot be called by a 3PD without using Reflection and basically hacking Joomla in memory. A VERY determined 3PD could already have an effect similar to freezing plugins using Reflection since Joomla 3.0. I may or may not have done something like that. I will admit to nothing incriminating, guv'nor!
Since the points in time where plugins are frozen are already logged should I assume we already cover your request?
17 days, no reply and no tests from anyone, I guess Joomla decided to go about it the Rocky IV way: “if he dies, he dies”.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-09-08 10:13:15 |
| Closed_By | ⇒ | nikosdion |
Is it possible to add a log entry for the freezing and melting in the joomla_update log please?