My plugin management interface is broken for unknown reason

  • You're welcome my friend ;)

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • At least, before any update, disable all plugin then update the panel.
    After update complete, check if new plugin version is available, if yes, update them and re-active after.
    It's what I've done from my update from 1.1.5 to 1.1.13 (OpenDKIM 0.0.1 to 0.0.6 (or 9 don't remember^^)).


    If I'm not mistaken, it's the way to do.

  • Hi,


    what do you think about that:
    - on update the installer disables all plugins
    - after update, the installer looks in i-mscp-plugins-repository for lates release of the installed and disabled plugins
    - if a plugin is latest release, the installer re-enables the plugin, if not, the admin has to re-enable the plugin (maybe with a message which plugins are not up2date) ;)
    - or, if possible, ask for update automatically


    @Nuxwin:
    please don´t kill me. :D

  • Re


    @FISA4


    Don't be afraid. I'm so horrible? =O


    It's not really possible to know whether or not a plugin, which is already installed, will stay compatible with a newer version. The plugins know with which API version (minimum version) they are compatible, but cannot know for the future.


    Normally, the compatibility problems should be rare. They should occur only between two release series. So far, it's my responsibility to ensure the backward compatibility for tiny versions (maintenance releases from the same serie such as 1.1.x). Thus, I'm in fault here but for my defense, I would say that the plugin API was not really stable and that many fixes and improvement were required...


    Regarding your advise: It's not so easy to disable all plugins using the installer because this last always come with the newest API. Of course, I could do something but this would be really hard to manage.


    However, what I can do easily during upgrade (using the installer) is to check whether or not a plugin is currently activated, and refuse to process the upgrade as long all plugins are not deactivated by the administrator. But again, this involves that when a plugin is deactivated, the customer data which belong to that plugin are not deleted, which is not the case of all plugins currently. So, even for this, I must talk to all plugin developers to be sure that they will do the needed changes prior any implementation. I will have a talk soon with the plugin developers ( @TheCry @mrpink @Ninos ) about this issue.


    For the record, disabling the plugins is not always sufficient. For instance, the problem encountered by @VirtualCed was hard to manage even by disabling the plugins. I had to update all its plugins manually (by copying the files in the plugins directory) because the last interface (plugins' management interface) was not compatible with the installed plugins and thus, I was unable to upload the new plugin versions using the interface.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206