En SPIP 3.1.1, lorsqu’on met en plugin maison (Plugin A) dans plugins-dist, il n’est pas désactivable. Cool, c’est le fonctionnement de base attendu.
Mais lorsque ce même plugin nécessite un plugin (Plugin B) qui est dans plugins/ et pas dans plugins-dist/, lorsqu’on désactive le plugin B, le plugin A est désactivé… Et cela crée une erreur, forcément.
Pour moi, il y a une incohérence. Si le plugin A qui est dans plugins-dist/ et nécessite le plugin B dans plugins/, le plugin B ne doit pas être désactivable.
Oui, je pourrais mettre le plugin B dans plugins-dist/ aussi. Mais là, n’est pas le soucis initial.
Est-ce que quelqu’un a déjà rencontré ce comportement ?
En SPIP 3.1.1, lorsqu'on met en plugin maison (Plugin A) dans
plugins-dist, il n'est pas désactivable. Cool, c'est le fonctionnement de
base attendu.
Mais lorsque ce même plugin nécessite un plugin (Plugin B) qui est dans
plugins/ et pas dans plugins-dist/, lorsqu'on désactive le plugin B, le
plugin A est désactivé… Et cela crée une erreur, forcément.
Oui mais la question pour moi est plutôt quel sens cela a -t-il de mettre
un plugins dans plugins-dist/ sans que ses dépendances y soient aussi ?
Pour moi aucun, car si le plugin a est obligatoire ses dépendances le sont
donc aussi.
Tu crois pas ?
Oui, mais il est plus facile de mettre un plugin dans plugins-dist que
toute "une flopée" de plugins. Cela permet par exemple d'avoir un plugin
qui nécessite toute une batterie de plugins pour la mise en place de la
"plateforme applicative".
Sans oublier, que SVP ne vas pas, corriges moi si je me trompe, vérifier la
disponibilité d'une mise à jour de plugins-dist et les mettre à jour. C'est
là, pour moi, tout l'intérêt d'avoir un plugin "maitre" (le fameux plugin
A) qui bloque la désactivation de certains plugins tout en bénéficiant de
la mise à jour offerte par SVP.