View Issue Details

IDProjectCategoryView StatusLast Update
0019337phpList 3 applicationPlugin APIpublic01-08-18 22:16
Reportermichiel 
PrioritynormalSeverityminorReproducibilitysometimes
Status assignedResolutionopen 
Product Version3.3.4 
Target Version3.4.0Fixed in Version 
Summary0019337: review the UX on plugins that stop having the dependencies and are automatically disabled
DescriptionOn https://github.com/phpList/phplist3/pull/379

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.
TagsNo tags attached.

Activities

duncanc

01-08-18 10:20

developer   ~0060969

Last edited: 01-08-18 10:25

View 2 revisions

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

return array(
    '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.

michiel

01-08-18 22:16

manager   ~0060979

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.