Gestion de versions pour les Modules de type "HTML personnalisé"

[woluweb]

Haaa combien de fois n'ai-je pas rêvé d'avoir la Gestion de Versions pour les Modules de type "HTML personnalisé" (tout comme on l'a pour les articles).
Hé bien R2H (les auteurs de R2H Image Manager p ex, qui permet d'identifier les images inutilisées sur son site) l'a fait !
C'est gratuit et c'est sur https://github.com/R2H-BV/moduleversion

[daneel]

ah ? Merci pour l'info, je n'aurais pas pensé que c'était un besoin.

Dans mes conceptions, je minimise l'introduction des modules html car on se retrouve facilement avec trop d'éléments séparés du contenu principal. A une époque, j'avais beaucoup trop de modules assignés ou non dans des positions spécifiques (en dehors des positions definies dans le template par défaut), la situation devenait ingérable de mon point de vue.

Désormais quand je conçois un article pour créer une page, les champs personnalisés remplacent essentiellement les informations des contenus html personnalisés. Par soucis de simplification, le module est dynamique et vient rechercher l'information qui est mis en cache.

Par exemple, qu'il s'agisse des horaires d'ouverture et de la position géolocalisée d'une entreprise, ou des publications du site vers GBP (Google Business Profile anciennement Google My Business) ou de la gestion de la politique de confidentialité (et liste des cookies installés), les informations évoluent ainsi dynamiquement ce qui évite d'oublier d'actualiser un module. L'autre particularité, c'est que je peux utiliser différentes sources comme les extensions installées, les champs personnalisés qu'ils soient liés à l'article affiché ou indépendants, l'api d'un service web externe (meteo pour la commune, infos de la bourse pour un site d'assurance et placement), etc.

Dans le coté dynamique, il faut penser par exemple à activer les plugins dans les modules personnalisés et utiliser l'extension Up de Lomart.

En général, le fait d'ajouter des révisions peut également alourdir le site inutilement si on a des centaines de pages (bien que défini sur 10 version max). Au développement, c'est ce que je désactive en premier dans la gestion des articles ainsi que les logs qui sont inutiles en local (je travaille de cette façon). En production et pour les rédacteurs, je réactive le versionning d'articles mais j'indique le moyen de purger ( un bouton comme avec le cache de litespeed mais cela vide les anciennes versions de l'article, catégories ou tags à la demande depuis la table #__history ). Ainsi, on peut offrir également un front en intégrant le workflow mais également des options de gestion qui seront liés aux ACL (droits).

En résumé, si on commence par avoir du contenu dans des modules avec un historique, ce sera certainement être intéressant pour certains sites mais ce n'est pas forcément ce que j'installerai pour éviter de retomber dans les problèmes que j'ai évoqué.

Dans l'optique d'améliorer le versionning, je verrai plus une option pour obtenir des stats tout autant que sur les éléments à la corbeille (article mais également menu et autres) afin de les gérer globalement en backend dans un outil d'optimisation. Je le note pour plus tard !