Pour maitriser l’ajout de plugins

Paquet.xml

  la définition des plugins

L’un des aspects et avantages majeurs de SPIP, c’est son système de plugins, à la fois simple à gérer dans l’interface comme à l’installation et à l’usage, et extrêmement rigoureux pour respecter toutes les possibilités de compatibilité entre versions de SPIP.

Mais comment ce fait-ce ?

Article publié le 2 mai 2021, et actualisé en juillet 2023

   
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

La programmation modulaire de SPIP fut la première des CMS à ouvrir les squelettes, par les possibilités de surcharge des squelettes, que ce soit dans Le dossier ./squelettes ou par l’usage de nombreux plugins [1]. A noter que SPIP lui-même embarque déjà de nombreux plugins internes, ceux qu’il appelle "verrouillés" dans l’écran deSVP... et il a donc fallu composer un système pour gérer les cohabitation entre ces centaines de plugins [2].
Cela peut aussi intervenir parce qu’un plugin surcharge un squelette (voire une fonction php) défini(e) par un autre,sans tenir compte d’un ordre historique ou alphabétique...
- les exigences de versions compatibles : au fil des évolution des sources de SPIP et de PHP, de nouvelles fonctionnalités sont ajoutées à certains plugins et les autres s’appuient dessus : si vous voulez installer un plugin récent sur un vieux SPIP, bien probable qu’une fonctionnalité soit manquante, vous arrêtant avec un beau message d’erreur....

Le calcul de dépendances de paquet.xml

Le fichier paquet.xml depuis SPIP 3.o énumère en particulier les plugins nécessaires ou utiles par des lignes (voir https://plugins.spip.net/redaction-...) référençant chaque plugin par son nom de préfixe, et l’intervalle de compatibilité par deux bornes : versions de SPIP initiale et limite ’estimée’ de compatibilité ! Et c’est là que le bât blesse !
Comme jusqu’en Avril, on parlait toujours de SPIP 3.3-dev parmi les "devs" de la "Team",ces bornes pour des plugins supposés compatibles SPIP3.3 ont été rédigées sous une forme analogue à [3.2.3;3.3.*] !
Patatras, on décide de numéroter en SPIP 4.0.... et depuis les plugins doivent tous être contrôlés et leur paquet.xml modifié en compatibilite="[3.1.0;4.0.*]" : de quoi fêter au travail tout le dimanche de fin de confinement....

Heureusement les "devs" de la "Team" sont intelligents et efficaces, donc "paresseux" ;-), et vous disposez d’une constante à définir dans votre mes_options pour forcer votre SPIP à se considérer comme une vieille version SPIP 3.x (uniquement pour charger des plugins SPIP 3).


Merci de nous signaler les coquilles, imprécisions ou erreurs qui figureraient dans cette page.

[1] Pour faire echo à une discussion récente, on connait à SPN de nombreux sites SPIP avec un minimum d’une cinquantaine de plugins actifs,entre les dépendances et les plugins outils invisibles !

[2] Chaque plugin estidentifié et les dépendances aux dizaines de versions de SPIP

Contraintes entre plugins

En fait deux sortes de contraintes sont automatisées pour l’éco-systeme de SPIP :
- les dépendances entre plugins : de nombreux plugins utilisent des facilités déjà développées[[L’exemple de Saisies est sans doute le plus explicite de ces dépendances, car celui-ci nécessite l’API de vérification (logique) et le plugin YAML (utilitaire de gestion interne SPIP du format éponyme), et il est lui-même très souvent utilisé pour d’autres plugins...


Liens A2A visibles seulement pour les inscrits.
Liens visibles seulement pour les inscrits.
   

Article publié le 2 mai 2021, et actualisé en juillet 2023 .

Répondre à cet article