View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019337||phpList 3 application||Plugin API||public||29-07-18 13:01||18-02-19 10:33|
|Summary||0019337: review the UX on plugins that stop having the dependencies and are automatically disabled|
Plugins that no longer match the requirements will automatically be disabled. This may need a notification to the user somewhere, as it will create an unexpected situation (eg functionality from plugins disappearing).
FYI @samtuke @xheni
PS this may be quite complicated to reproduce. We may want to consider having some test plugin for this purpose.
|Tags||No tags attached.|
Currently the dependencies for a plugin are evaluated by calling a method of the plugin. This means that the decision to allow enabling a new version of a plugin can be made only after overwriting the plugin with that new version and creating an instance of the plugin.
My suggestion is to put the dependencies into a stand-alone file which can be evaluated after downloading the plugin zip file but before overwriting the current version of the plugin. If the dependencies fail then do not allow updating the plugin.
Possibly the same could apply to installing a plugin too.
The reason that this problem arose is that I wanted to have a requirement of phplist 3.3.2 or later, when there is ordered activation of plugins. But someone can upgrade a plugin even though they have an earlier version of phplist.
The stand-alone file could be similar to the dependencyCheck() method, e.g.
'PHP version 5.4.0 or greater' => version_compare(PHP_VERSION, '5.4') > 0,
'phpList version 3.3.2 or later' => version_compare(VERSION, '3.3.2') >= 0,
which can be processed by a require statement.
Yes, I think that's a good idea. Fetching a file with metadata before actually applying it.
Apart from dependencies, we could allow other info, but that may be of later concern.
This requires writing some docs on it, and then applying. We should also think of a fallback, when the file has not been defined.