This PR will standardize the uninstall task for our extension install adapters so that they all will run through the same logical processing with the same base defined feature set. This also implements a round of additional refactoring and updates to address some known issues.
Specific changes thus far include:
Library uninstalling should now include its manifest script
Library and package extensions load language files during uninstall (#14087)
Added abstract finaliseInstall() method to base adapter class (used in all subclasses, missing in the base class though)
Added standardized uninstall path
All extension types should now support SQL install/update/uninstall
Extension updates are purged when uninstalling them for all types now
Testing Instructions
Uninstalling extensions should use the streamlined path and all features consistent on all adapters.
Documentation Changes Required
B/C Issue - Added abstract methods to base install adapter class, these must be implemented in subclasses
Right now this PR is at a point where the uninstall path for all of the adapters is now standardized, the process is now:
Load extension database record, abort if not found
Check if protected, abort if so
Check if part of a package that blocks child uninstall, abort if so
Setup the uninstall job based on the adapter's needs, this is where the adapters are responsible for loading the manifest file into memory, setting paths to the installer library, loading language files, and performing any checks that should abort the process
Load the extension's manifest script and trigger the uninstall task
Process the extension's <uninstall> tag (the SQL queries defined by the extension to be run at uninstall)
Remove the extension's files from the filesystem
Finalize the job (this is where if there are any update records exist for the extension those are removed, the record removed from the #__extensions table, and any other post processing that may be required for the adapter is performed (i.e. templates removing template style records, modules removing the menu assignments, etc.))
If we're going to address #16166 this would be the time to do it because it will require all developers to review their pre/postflight jobs as most are probably coded in a way that they only run for install/update tasks.
I should be able to tackle #6015 but I'd rather do that after this first round of updates (which is a mildly major effort) is tested out that way we aren't chasing our tails on too many items at once.
joomla-cms-bot
- 
wilsonge
-
Right now this PR is at a point where the uninstall path for all of the adapters is now standardized, the process is now:
<uninstall>tag (the SQL queries defined by the extension to be run at uninstall)#__extensionstable, and any other post processing that may be required for the adapter is performed (i.e. templates removing template style records, modules removing the menu assignments, etc.))If we're going to address #16166 this would be the time to do it because it will require all developers to review their pre/postflight jobs as most are probably coded in a way that they only run for install/update tasks.
I should be able to tackle #6015 but I'd rather do that after this first round of updates (which is a mildly major effort) is tested out that way we aren't chasing our tails on too many items at once.