Le puissant développement modulaire et ses risques

LES MODULOTHÈQUES / EXTENSIOTHÈQUES : LES MEILLEURES ALLIÉES ENNEMIES

Point d’orgue de ces CMS : proposer à la communauté des codeurs, des possibilités d’étendre la base du moteur initial. Il y a en effet pratiquement un module pour tout. Sauf évidemment pour les « petits » ajustements du client, mais ça l’histoire aura tendance à l’oublier. Donc oui si ces modules peuvent aller du simple ajout automatique de bouton de partage social, jusqu’à l’ajout d’une boutique e-commerce entière, il ne faut pas perdre de vue que cela fera les choses telles que l’ont décidé les auteurs et que toute modularité de facade avancée, elle n’en sera forcement que toute relative. On dit que c’est dans le détail que se cache le diable… et bien malgré le côté séduisant de la vitesse d’amorce citée ci-dessus, c’est bien à ce stade que les choses vont se compliquer, car des détails il va assurément en pleuvoir.
Et l’ajout massif et sans limite des modules, sera certes grisant, mais rendra les derniers mètres pour atteindre le nirvana « du comportement fonctionnel ultime » d’une longueur interminable.

WordPress : nous avons ici des modules au kilomètre pour satisfaire les désirs fonctionnels les plus fous. Contrat rempli de ce côté vous pouvez foncer tête baissé.
Mais, tout de même, petites spécificités des extensions de WordPress :

• La qualité du code extrêmement variable de la programmation de ces extensions. Surtout ne cherchez pas à afficher les erreurs PHP sous peine de commencer à douter du bien fondé de votre choix de CMS (que nous haïssons ces moments de doute où l’on re-vérifie par deux fois si l’on n’a pas récupéré par erreur une version en branche DEV). Et donc par la même, vous allez finir par vous questionner sur votre capacité intrinsèque à faire cohabiter vos sacro-saints principes dans l’outil : pourquoi se debugger quand l’outil lui-même nous parasite. Les logs d’erreur seraient-ils passés de date de nos jours ?
• La compatibilité erratiques des extensions. En effet, après le code spaghetti, on apprend ici à relever un peu le goût avec le code spaghetti aux Hooks. Alors pour ceux qui ne connaissaient pas, c’est une recette extrêmement conviviale qui permet de mettre un peu de tout et surtout n’importe quoi dans la marmite. Pour au final aboutir sur l’assurance de brouiller toutes les saveurs. Là encore, prévoir des grands moments de doute, et des appels à l’aide réguliers aux super-debuggeurs des alentours. Cela va sans dire : éviter de trouver des extensions qui se marchent sur les fonctionnalités : elles ne feront pas du tout bon ménage. Pire encore elles pourraient même bien cacher leur jeu jusqu’à la fatidique découverte de données frauduleuses sournoisement entrain de se jouer de vous.
• Le système de licence alambiqué. Les extensions de nature gratuite qui s’entremêlent avec des extensions aux divers systèmes de licences payantes (par domaine unique, multi-domaine, par clé…) rendent extrêmement confu la maintenance du site en organisation prestataire/client. Et complexifie par la même d’un sacré degré l’usage d’environnements multiples (vous savez, les fameux trois frères, DEV, STAGING, PROD).

Drupal 7 : La aussi plutôt conséquente pour ce CMS, on appréciera, par rapport à son voisin WordPress, le niveau de sérieux/qualité plus élevé des programmes proposés. Basé sur des concepts similaires (les hooks) on retombe parfois sur des travers partagés, mais la structure proposée laisse déjà moins de place aux fantaisies les plus déraisonnables.

Drupal 8 : Alerte spéciale concernant cette nouvelle version du CMS. Changer le moteur en profondeur expose bien évidemment la communauté à opérer une grosse courbe de ré-apprentissage. Et de fait les modules mastodontes ne s’en retrouvent pas du tout tous exploitables à l’heure actuelle. Et l’on apprend ainsi honteusement à pousser un « ouf » de soulagement quand une version APLHA (ou DEV …) pointe le bout de son nez sur la page officielle du module (ou sur un GIT non officiel…). Résultat Drupal 8 est certes plus puissant, carré, moderne, pro etc etc … mais ne permet pas pour l’heure de revendiquer une modularité à toute épreuve comparée à son ancêtre version 7. Tout du moins pas dans le cadre d’un CMS « prêt à websiter » tel qu’on nous le vend au travers du message Drupal.

LES THÉMOTHÈQUES

Sur la même base que les modules/extensions, nous pouvons trouver sur les sites spécialisés un large choix de thèmes disponibles pour habiller en 2 clics nos FrontOffices.

WordPress / Drupal 7 : Ici c’est assez simple, nous pouvons reprendre les mêmes freins et remarques que ci-dessus. Les expériences de déploiement sont plus au moins agréables en fonction des qualités de confection de ces bouts de code. Attention à ne pas céder trop vite aux appels des sirènes de l’économie de temps et de budget sur ce poste du développement :

• une adaptation d’une base n’est pas toujours facile… et peut finir par devenir au final plus chronophage que d’avoir fait le choix initial de créer son propre thème « from scratch ».
• il faut bien garder en tête qu’un thème dans ces systèmes CMS est loin de n’être qu’une intégration CSS. Ce qui peut poser d’énormes problèmes de compatibilité avec l’ensemble des modules mis en place, et lors de la future procession des mises à jour core/module qui aura inéluctablement lieu.

Drupal 8 : Qui dit Drupal 8, dit Symfony, dit Twig. Autrement dit un nouveau système de template « optimisé pour » en sus et place du bon vieux template à la mode PHP. Ici pour notre expérience concrète sur la question, fort de notre expérience passée sous Drupal 7, nous avons fait le choix d’acter pour le portage du système de thème Zen. A bien comprendre qu’il ne s’agissait pas de profiter de la beauté toute figée d’un thème « prêt à déployer », mais plutôt de rester dans le cadre d’une proposition d’implémentation et de structures afin de réaliser notre propre création. Et la ce fut la stupeur. De souvenir d’une simplicité limpide… nous sommes tombés dans un délire hiérarchique total à la complexité que nous trouvons finalement peu justifiée. Nous mettrons notre choix stratégique sur le coup d’un jugement maladroit et on ne nous y reprendra certainement pas. Force est de constater : les bons tuyaux de Drupal 7 ne seront clairement pas ceux de Drupal 8. Mais c’est dans le fond normal : l’outil change ses bases et ça lui donne une sacré bonne excuse !

Mais s’il y a bien des complexités reconnues dans toute production Web, comment « nos voisins côté Framework » s’en sortent-ils ? Car maintenant qu’on en parle : où se trouvent toutes ces belles initiatives structurantes dont on entend vanter monts et merveilles sur le reste de la toile ?