Plugin or not ?

Le Plugin est une nouveauté à plusieurs titres dans Spip. A titre anecdotique c’est l’introduction d’un mot qui n’est pas Français dans le vocabulaire Spipien, un précédent car on a vu depuis des balises comme #SET.

C’est aussi le fait de développeurs, en général distincts de l’équipe Spip qui s’organisent sur "la zone" pour collaborer au développement sous SVN, avec 2 listes de discussions dédiées.

Enfin bien sûr, c’est une nouveauté technique même si le concept a été expérimenté avec succès sur plusieurs projets du monde Open source (Mozilla, Eclipse...).

L’idée c’est de pouvoir enrichir Spip pour un besoin particulier en intervenant dans le noyau, pour utiliser un mot qui n’eut pas déplu à Molière. En effet, les squelettes ont certaines limites (sans cesse repoussées d’ailleurs) que l’on peut faire sauter en recourant au php, mais à partir d’un certain point on se rend compte qu’il faut intervenir au niveau du noyau. Alors pourquoi ne pas créer dans le noyau des points d’ancrage convenus pour des modules apportant de nouvelles fonctionalités ? L’architecture de Spip comportait 2 niveaux (le squelette et le noyau), elle en comporte maintenant un troisième.

L’idée, comme on l’a vu, a fait déjà ses preuves, mais la pratique n’est pas dénuée d’écueils.

Dans le noyau, il faut réaliser les points d’ancrage et s’assurer que la cohabitation est assurée sur l’ensemble noyau + plugin, sachant que l’on aimerait accepter plusieurs plugins en même temps. Ceci passe par la définition d’un ensemble de règles qui peuvent parfois être vérifiées par le noyau mais pas toujours ; comment se prémunir efficacement d’un Plugin "déviant" qui ne joue pas exactement suivant les règles ? Comment assurer la cohabitation sans incompatibilités ?

Dans la pratique, l’utilisateur est en prise directe avec cette combinaison a plusieurs niveaux, et c’est évidemment une complication pour lui d’avoir à intégrer Spip, un squelette et 1 voire plusieurs Plugins et ce d’autant plus que le noyau évolue de son coté à bonne vitesse ! L’idéal pour un utilisateur final serait que les développeurs de squelettes de site (voire même de Spip) intègrent des Plugins mais par définition ou presque, les Plugins répondent à des besoins particuliers alors pourquoi les intégrer dans des squelettes généraux ?

La question se pose quand même avec Epona pour 2 Plugins : "recherche de squelette par mot-clé" . et "Agenda" car ils proposent des fonctions déjà présentes dans le squelette.

Dans Epona, la sélection de squelette par mot clé est réalisée par une boucle avec critère de mot-clé, soit 5 lignes à comparer avec la taille du Plugin "Chercher squelette" qui en compte 900. De plus, la configuration du squelette entier est non seulement facultative mais plus simple que celle du seul Plugin. Alors pourquoi substituer le Plugin à la boucle ?

Le Plugin Agenda permet de saisir des événements associés à un article, ce qui est déjà possible avec Spip en utilisant, de manière détournée, la date de rédaction antérieure comme le fait Epona. Ce Plugin est une belle réalisation technique particulièrement bien intégrée à la partie privée et il a une valeur exemplaire notamment sur la création de nouvelles boucles dans Spip. Mais contrairement à ce que le nom laisse penser ce n’est pas un Agenda : plutôt une base qui permet de créer l’Agenda. Cela vaut-t-il les 9 000 lignes de code associées (agenda + widget_calendar) ? D’autant qu’en l’état actuel, il perd la compatibilité avec le noyau à chaque version de Spip.

Il est vrai que ces 2 Plugins apportent des subtilités par rapport à une solution plus "Spipienne", mais ils n’apportent pas de plus value significative par rapport à ce qui est déjà implémenté dans Epona.

Pour le moment je ne vois pas de Plugin qui apporterait un vrai plus au squelette, donc pour répondre à la question, celle qu’aurait pu poser Hamlet, hé bien .... Wait and see !