Plugin again ....

Au risque de passer pour le Gaulois de service, celui qui résiste à l’envahisseur, voilà (après cet article) un autre argumentaire qui n’est pas à la gloire des Plugins. Attention, il s’agit ici de l’utilisation de Plugin pour Epona et pas avec Epona car il n’est pas question d’interdire les Plugins sur Epona ; le Gaulois n’est pas foncièrement anti-Romain non plus !

La question que je me pose depuis un certain temps est de savoir comment configurer Epona avec un Plugin et en quoi il serait intéressant de le faire. Maintenant cette possibilité existe avec le Plugin cfg (ici sur Spip-contrib), alors quel en serait l’intérêt ?

Epona dans sa présentation la plus dépouillée s’installe par simple dépôt de fichier. Il n’exige aucune configuration, aucune altération de la base de donnée, aucun changement de fichiers existants. En bref, ça n’impacte que /squelettes. Il ne peut pas y avoir plus simple, sauf à intégrer Epona dans Spip lui même !

Si maintenant on souhaite davantage (un Agenda par exemple), il faut configurer Epona, c’est à dire ajouter des éléments basique de Spip : pour l’essentiel des mot-clés. Là encore, aucune altération du schéma de la base ou des fichiers existants. On peut donc configurer le squelette à la main, via la partie privée de Spip ou, ce qui est plus agréable, via un configurateur (livré avec le squelette) qui automatise la chose. Sa mise en oeuvre est courte : ouverture de la page de configuration, 1 ou 2 clics et la totalité des options Epona est installée dans la seconde. Comment faire plus simple ? Impossible, même si ce n’est pas un mot Gaulois.

Utiliser un Plugin de configuration (en l’occurrence cfg) pour faire la configuration Epona rendrait la vie un peu plus compliquée au Webmestre. Déjà il faudrait activer cfg lui-même puis le Plugin Epona (pourquoi alors ne pas mettre le configurateur lui aussi en Plugin ?) et là, on a déjà consommé nos 2 clics. Rien de terrible mais le Webmestre n’a rien gagné non plus. De mon point de vue fabriquant de squelette, je ne vois pas non plus ce que j’y gagnerai si ce n’est un squelette plus lourd, ce qui est tout l’opposé de ce que j’ai cherché à faire jusqu’ici. Il est vrai que cfg n’est pas indispensable pour Epona tant que celui-ci en reste à la création de mot-clés pour la configuration, mais c’est précisément la simplicité du squelette qui fait son intérêt.

Une question plus sérieuse concerne l’indépendance du squelette par rapport à son configurateur.

Actuellement cette indépendance est totale : le squelette, que ce soit dans sa version de base ou avec les options (Agenda...), peut être installé sans le configurateur. C’est un immense avantage car le squelette est installable avec n’importe quelle version de Spip à venir, pour autant que Spip maintienne la compatibilité de la partie publique, ce qu’il a toujours su faire jusqu’à maintenant. Avec un Plugin comme cfg, on n’aurait pas la même garantie car la partie privée de Spip est loin d’avoir la stabilité de la partie publique. Je ne parle pas de la stabilité du Plugin, ni des interférences plugin-noyau ou inter-plugins qui sont autant de problèmes potentiels.

En l’état du squelette et de Spip, un Plugin de configuration serait à mes yeux une régression. Evidemment, il se peut que de nouvelles fonctionnalités rendent nécessaire cette régression, donc rien ne dit que le Gaulois résistera toujours. Je ne demande qu’à être convaincu