Faut-il utiliser les modules de la communauté Drupal
Utiliser des modules de la communauté
« Pour ne pas réinventer la roue »
Nous sommes absolument d’accord. Cependant le CMS Drupal est un Framework, notamment destiné dans les projets Genious Interactive au développement sur-mesure. Ce dernier est imposé souvent par le demande de mise en place de fonctionnalités « inédites », ou exigeant une réponse technique et fonctionnelle 100% adaptée aux besoins du client.
Lorsque nous proposons un devis à nos clients pour des fonctionnalités à mettre en place sur un site Drupal, ils demandent parfois :
« Il n’y a pas un module Drupal pour ça ? »
« J’ai trouvé le module http://www.drupal.org/project/ce-module-fait-justement-ce-que-je-veux pour faire ça, pourquoi ne l’utilisez-vous pas ?! »
« C’est très cher ! Pourtant j’ai entendu dire qu’il existe un module qui fait exactement ce que je veux… »
Nous allons vous exposer les principaux critères que nous prenons en compte lorsque nous choisissons d’utiliser, ou au contraire d’éviter d’utiliser, un module de la communauté (aussi appelé module « contrib »).
Une solution technique adaptée à un besoin
Pour répondre à une demande fonctionnelle, les premières questions à se poser sont :
- La fonctionnalité aura-t-elle une forte valeur ajoutée ?
- La fonctionnalité sera-t-elle amenée à évoluer ?
- D’ordre général, votre site sera-t-il maintenu ? (les mises à jour de modules seront-elles effectuées, par qui, prévoyez-vous des évolutions pour votre site, souhaitez-vous souscrire à une maintenance annuelle pour la correction d’éventuels bugs…)
Par exemple, si la fonctionnalité a une faible valeur ajoutée (c’est un « bonus » pour vous) et que vous ne souhaitez pas la faire évoluer, l’utilisation d’un module contrib peut s’imposer d’elle-même. Si notamment son utilisation ne répond pas à vos moindres désirs il est probable que vous serez prêts à faire des concessions.
Si la fonctionnalité a une forte valeur ajoutée (elle est centrale dans votre site Web, critique pour votre communication…) et que vous prévoyez des évolutions dans les années à venir, il est souvent plus intéressant de travailler sur un développement sur-mesure qui couvre 100% de vos besoins présents et futurs.
Choisir un module, est-il « vivant »
Les modules Drupal sont presque tous gratuits, c’est à dire que pour la plupart ils sont, soit maintenus par des développeurs pendant leur temps libre, soit maintenus par des sociétés qui les ont développés pour un client. Dans ce deuxième cas, ils les maintiennent souvent hors des cas d’utilisation prévus pour le projet initial de leur client.
Il n’est donc pas rare (voir même très fréquent) que les modules contrib soit peu (moins d’une mise à jour par an), voire plus du tout maintenus (pas de mise à jour depuis plusieurs années)
Donc, dans le choix de l’utilisation d’un module, la première question à se poser est « Est-il encore maintenu ? »
Pour répondre à cela, on peut observer plusieurs données sur le site Drupal.org :
Dans la partie « Project Information », on pourra vérifier si le projet est marqué comme actif (Under active development):
On regarde ensuite la date de dernière « Recommended release » (version stable du module), par exemple ici avec le module Views :
Elle est très récente car le module a fait l’objet d’une mise à jour de sécurité il y a peu.
Il faut également regarder la date de dernière mise à jour de la version de développement, indiquant si le développeur continue à corriger des bugs :
N.B. : Il n’est pas rare que ces deux dates soient très éloignées : le développeur maintient la version de dev, mais ne publie pas de version stable. Contrairement à ce que l’on pourrait croire, cette situation est en général très mauvaise. Le développeur ne prend pas la responsabilité de publier une version stable de son module, il ne s’engage pas sur sa stabilité. Et techniquement les versions de développement peuvent générer de gros problèmes de maintenance et de sécurité car il n’existe pas de mise à jour de sécurité pour les versions de développement.
Le module est-il évolutif
Les modules peuvent parfois faire gagner du temps, mais pour répondre à 100% de vos exigences ils peuvent s’avérer inadaptés. Les faire évoluer pour correspondre à vos besoins peut demander plus de travail que si le module n’avait pas été utilisé.
On peut classer les modules Drupal dans deux grandes catégories :
- Les modules API
- Les modules de site-building
Les modules API
Les modules API sont destinés aux développeurs. Ils offrent des outils permettant de simplifier les développements notamment en proposant ce que l’on appelle des « design pattern« . Ils sont mieux maintenus que les modules de site-building car ils sont maintenus par des développeurs expérimentés et plus souvent impliqués dans la communauté Drupal. Ils sont destinés aux développeurs qui connaissent Drupal et son API native.
Utiliser des modules API permet effectivement de ne pas avoir à réinventer la roue. On les adopte en général facilement, surtout s’ils peuvent être utiles pour plusieurs fonctionnalités du site. Les modules API sont par définition évolutifs, car ils sont une base pour le développement et ne proposent pas de fonctionnalités à proprement parlé.
Les modules de site-building
Les modules de site-building sont des modules plus modestes, plus simples, développés par des développeurs parfois peu expérimentés, pour répondre à de petites problématiques du type :
« Proposer des boutons de partage sur les pages de noeud »,
« Intégrer un Slider Javascript à une vue »,
« Customiser le fil d’ariane »
Ils sont destinés aux site-builder : des intégrateurs ou webmasters qui ne maîtrisent pas la programmation PHP de manière avancée. Ils permettent de proposer des fonctions courantes, avec un niveau limité de personnalisation, pour des techniciens qui connaissent peu ou pas du tout Drupal.
Utiliser des modules de site-building a peu d’intérêt pour une équipe de développeurs Drupal. Ils sont peu ou pas évolutifs, et plus le nombre de modules utilisés dans un site Drupal augmente, plus il peut devenir difficile à maintenir, être en proie à des régressions et à de mauvaises interactions entre les modules.
Entre les deux
Certains modules combinent ces deux aspects. Ils proposent de bonnes fonctions de site-building, permettant aux techniciens non-développeurs de mettre en place des fonctions avancées, parfois profondément ancrées dans Drupal. Et ils proposent en parallèle une bonne API, source riche d’outils pour les développeurs pour exploiter les fonctions du module et les faire évoluer.
Quelques autres critères
Le module propose-t-il une version stable ?
Parfois, tout simplement, le module en question ne propose pas du tout de version stable.
Par exemple, seule une version de développement est disponible. Dans ce cas, nous ne pouvons l’utiliser car, comme évoqué précédemment, leur maintenance par leur développeur n’est pas assurée et les mises à jour de sécurités ne sont pas surveillées ni déployées via le système de mise à jour standard Drupal.
Une version beta est parfois disponible, il faut donc vérifier sa fiabilité et il arrive que nous en exploitions.
Nous n’exploitons jamais de version alpha, elles présentent les mêmes inconvénients qu’une version de développement.
Combien de modules contrib faut-il ?
Les modules Drupal peuvent parfois être dépendant les uns des autres. Aussi, pour répondre à un besoin donné, faut-il s’assurer que le nombre de modules contrib est en adéquation avec la valeur ajoutée de la fonctionnalité pour le client.
Le module est-il multi-langue
Dans Drupal 7, le support multi-langue n’est que partiellement natif. Il n’est pas rare que certains modules soient développés par des anglophones pour des anglophones, et dans ce cas les développeurs ne se préoccupent pas de l’aspect multi-langue de leur module.
Pour la traduction de contenus Drupal, les pratiques recommandées sont axées (dans l’esprit de Drupal 8) vers ce que l’on appelle la traduction d’entités (entre autres via le module Entity Translation). Cette technique est relativement récente et nombreux sont les modules qui ne supportent pas la traduction d’entités.
Qu’utilisons-nous à Genious Interactive ?
Les sites de nos clients comportent souvent la même base de modules Drupal, pour proposer les fonctions de base d’un site ou d’une application Web :
- Réécriture d’URL : Pathauto, Transliteration, Global Redirect, éventuellement Pathologic.
- Ergonomie : Admin menu, Coffee, Module Filter, Colorbox
- Contribution : CKeditor (+ éventuellement Linkit)
- Outils « système » et de développement : Elysia Cron , Devel, Features, Strongarm, Diff
- SEO : Metatag, Google Analytics, XML sitemap
Pour le développement de fonctionnalités courantes, les principaux modules Drupal que nous utilisons sont :
- Gestion des entités : Entity API, Entity Reference, éventuellement References dialog
- Multi-langue : i18n, Localization update, Entity Translation
- Et autres API : Views (l’inévitable), Rules, Date API, Libraries API, Chaos tools (requis par bon nombre de modules)