Fixed Uninstalling Addon - Backend/CLI don't behave the same way

MaGeFH

Active member
Affected version
Release Candidate 3
I noticed that when uninstalling an AddOn the behavior of XF2 differs between Admin CP and CLI.

When uninstalling via Backend, the class extensions seem to be valid until the very last step has passed. In CLI mode this is not the case and you will be given something like "The site is currently being upgraded. Please check back later." when trying to access methods that are available via your class extensions.

To easily reproduce this, I have created a small "testme" addon. This logs into the Server error logs (admin.php?logs/server-errors/) during installation and uninstallation. The CLI also does flag hasPendingUpgrade to true, so I needed to set \XF::app()->error()->setIgnorePendingUpgrade(true); to log to the server error log during CLI install/uninstall.
 

Attachments

Thanks for that test case. We sort of knew about this. We only started to handle this differently in RC3 for the CLI process. In terms of the Admin CP, it really only applies for the first uninstall step, e.g. if you add an uninstallStep2() method with the same code the result will be different when it hits that step because by then we've done a redirect which will have properly rebuilt any cached extensions, listeners etc. that have been disabled.

We will be able to sort this though, so leave it with us.
 
It's worth noting that regardless of any action we take, you shouldn't ever be relying on your listeners/etc being available during uninstall. The simple test case there is to uninstall a disabled add-on. (We'd never force an add-on to be enabled to uninstall, as that itself could prevent uninstallation.)

Similar things apply to upgrades which would likely have the same behavior as here. (If you need to rely on your code to do things, you should use postUpgrade() to trigger the code/jobs; your add-on is guaranteed to be enabled then.)
 
It's worth noting that regardless of any action we take, you shouldn't ever be relying on your listeners/etc being available during uninstall. The simple test case there is to uninstall a disabled add-on. (We'd never force an add-on to be enabled to uninstall, as that itself could prevent uninstallation.)

I agree. Good to know this will be addressed. Now that I know for sure, I will build accordingly!

Thanks for the quick reply. :)
 
This has been sorted now for the next release. The test case logs the expected messages now in both cases.
 
Top Bottom