-
New Feature
-
Resolution: Fixed
-
Minor
-
5.0
-
MOODLE_500_STABLE
-
MOODLE_500_STABLE
-
MDL-79843-main-fix -
-
-
-
5
-
Team Alpha - Sprint 2 I2-2024, Team Alpha - Sprint 3 I2-2024, Team Alpha - Planning I3-2024, Team Alpha - Sprint 1 I3-2024, Team Alpha - Sprint 2 I3-2024, Team Alpha - Sprint 3 I3-2024, Team Alpha - Planning I4-2024, Team Alpha - Sprint 1 I4-2024, Team Alpha - Sprint 2 I4-2024
This issue is scoped with creating a working model for deprecating subplugin types (or plugin types for that matter) - something we've not needed to do before, but will need to do as part of the end-of-life-ing the mod/lti/service subplugins in MDL-79109 (and, more specifically the task issue MDL-82299).
At a high level, the goals are as follows:
- Don't break an upgrading site when 3rd party plugins are installed and the site upgrades to a new Moodle version, where these subplugin types are no longer supported (and are deprecated). We need to allow these plugins to exist, albeit in a deprecated state.
- If a plugin type is to be deprecated, core plugins will have to be moved/deleted first, however, this doesn't stop 3rd party plugins from being present in a given site.
- Make it clear, during upgrade, that xxx plugins of the plugin type yyy are deprecated
- Permit uninstall of the deprecated plugins/subplugins via site admin. While no code will call the plugin classes (this should have been removed prior to deprecation), we also need to allow clean removal of the plugins from the DB + file system, just like any other plugin.
- Include some sort of indicators on the plugins overview in site admin (deprecated, end of life, whatever).
- Ensure any async execution of plugin code is prevented while the plugin is still installed pending migration/uninstallation. Essentially, deprecation should only permit 3rd party maintainers to get their data out of the old plugin, should they need to (permitting things like migration to a replacement plugin type, for example). E.g. we need to ensure things like the following won't be executed within deprecated plugins:
- Hooks
- Callbacks + Class callbacks
- Events
- Tasks
- Web services
- Others ?...
I'm proposing we implement a 3 phase deprecation process, as follows:
- Phase 1 - Deprecate
- Achieved by adding a 'deprecatedplugintypes' entry to either components.json (core plugin types), or subplugins.json (for the respective plugin containing subplugins).
- Move any deprecated plugin from the 'plugintypes' array to the 'deprecatedplugintypes' array
- Bump version (not strictly needed since allversionhash will catch phase 1, but needed for phase 2)
- Phase 2 - Delete
- Achieved by adding a 'deletedplugintypes' entry to either components.json (core plugin types), or subplugins.json (for the respective plugin containing subplugins)
- Move any deleted plugin from the 'deprecatedplugintypes' array to the 'deletedplugintypes' array
- Site upgrade blocked (env checks require removal of deleted plugin type plugins)
- Phase 3 - Final removal
- Remove the entry from 'deletedplugintypes' array entirely
- blocks
-
MDL-79109 Migrate the bulk of the mod_lti plugin to Moodle core.
-
- Development in progress
-
-
MDL-82299 Deprecate 'ltiservice' and 'ltisource' subplugin types
-
- Open
-
- caused a regression
-
MDL-84438 Regression from MDL-79843 due to uninstalled plugins
-
- Closed
-
-
MDL-85123 Tests in plugin_manager_test may fail because of other installed plugins
-
- Closed
-
- has been marked as being related by
-
MDL-66239 Document various deprecation processes
-
- Open
-
- Testing discovered
-
MDL-84355 PHPUnit configuration should exclude fixtures
-
- Closed
-