Aperçu des mains d'un développeur qui code avec Drupal sur son ordinateur

Drupal est-il has been ?

Après  vingt ans de bons et loyaux services,  Drupal a-t-il suffisamment évolué pour rester dans la grande course technologique du web ? 

Commençons par la base : PHP 

Historiquement, les services informatiques des grands comptes n'avaient pas une très haute opinion du langage PHP…  D’autant plus que cette même opinion provenait d’un univers logiciel plus lourd,  notamment en JAVA (voire d'autres dinosaures maintenant oubliés), nécessitant des dizaines de serveurs pour tourner correctement et des temps de compilation non négligeables. PHP endossait alors l'image d'un langage destiné uniquement à mettre en œuvre des blogs et des sites personnels. 

Pourtant PHP est toujours là, dominant 78% du web mondial ! Trêve de suspens, donc : PHP est loin d’être ou même de devenir has been ! 

Les standards de programmation 

Une réputation longtemps discutée

Drupal a longtemps souffert de la réputation d'être à la traîne et de rebuter les développeurs les plus à la pointe. Jusqu'à Drupal 7, les notions de programmation orientée objet étaient en effet les grandes absentes des logiques Drupal. 

L’usage de PHPTemplate rentrait également au chapitre des sujets sensibles… PHPTemplate permet d'exécuter du PHP jusque dans la couche de mise en page, ce qui va à l'encontre de toute logique de développement moderne. Certes, ce n’est pas une bonne pratique, mais cela reste faisable malgré tout.  

La solution proposée par le module features pour porter des configurations d'un environnement à l'autre (les paramètres d'un type de contenu depuis le poste du développeur vers l'environnement de test, par exemple) n'était pas non plus exempte de défauts. La solution n'étant pas embarquée dans le cœur de Drupal, elle n'était donc pas généralisée et chaque équipe avait sa propre façon de faire, ce qui rendait la reprise de projet autant complexe que périlleuse. 

Avec l’arrivée de Drupal8 et l’intégration des logiques Symfony, nous repartons sur des bases plus modernes ! 

Un changement bienvenu avec l'arrivée de Drupal8

La transition des versions 7 à 8 a demandé un  travail colossal aux équipes du cœur de Drupal et celles des modules issus de la contribution. Le passage à la norme PSR4 (PHP Standard Recommendation), la gestion de dépendance, de la POO (Programmation Orientée Objet) partout, c'est bon : tout est là ! Le système historique des hooks s'efface pour laisser la place aux events et aux plugins. 

Avec l'arrivée de Symfony s'est également invité Twig (tous deux portés par Fabien Potencier et SensioLabs), au revoir donc, à ce vieux PHPTemplate ! Il a fait son temps et nous ne le regretterons pas... Twig permet de réaliser de la mise en page dans un langage simple, mais élégant, et surtout rendant impossible l'ajout de PHP directement dans les fichiers de template. 

Finies les features, place aux fichiers au format YAML (Yet Another Markup Language) ! Toute la configuration est maintenant rationalisée dans un seul format, à un même endroit, de façon lisible et facilement « transportable » via le versionning de fichier. 

Usine à sites Drupal : que gagnez-vous à l'adopter ?

Un gestionnaire de dépendance 

L'usage de Composer pour organiser tous nos modules, tous nos patchs, et toutes les dépendances qui en découlent a été généralisé depuis Drupal8. 

Si vous n'êtes pas familier avec Composer, sachez avant tout que l'idée maîtresse est de disposer d’un outil qui gère et rapatrie tous les composants externes de notre projet, et de pouvoir uniquement versionner dans notre GIT le code que nous avons réalisé. 

Par exemple, si j'ai besoin du module Webform dans mon projet, je ne vais pas le télécharger à la main dans le répertoire de mon projet, puis aller répéter l’opération sur les postes des autres développeurs, sur l'environnement de test, puis sur l'environnement de production... et cela pour chaque module... Bref, Composer s'occupe maintenant de cette action, mais il va aussi s'occuper de rapatrier les éléments externes dont le module Webform pourrait avoir besoin, comme une librairie javascript pour générer les captchas. 

A se demander comment on faisait avant ! 

Vous avez demandé l'API, ne quittez pas 

La mode étant au découplé et à l'omnicanalité, comment Drupal s'inclut-il dans cette mouvance ? En rendant tous ces contenus accessibles via webservice nativement (oui, oui), uniquement grâce au cœur de Drupal. Il reste encore du travail pour les éléments autres que les contenus, notamment les menus, afin que l'ensemble des fonctionnalités natives de Drupal puissent être utilisables nativement via webservices, mais ces points sont dans la roadmap, et actuellement en cours d'avancement. Que cela ne vous arrête pas, des outils comme Gatsby documentent déjà leur implémentation de Drupal ! 

Et pour les 20 ans à venir ? 

Mes dons de divination ne sont pas si développés ! Je ne vois cependant aucune raison technologique à ce que Drupal tombe en désamour dans les prochaines années. 

Une pérennité assurée

L'évolution des sites actuellement construits avec Drupal s’annonce même  plus pérenne que jamais : la migration entre les versions majeures  se traduisait auparavant en projets à part entière. Elle se résumait même souvent à un tout nouveau site ou projet dans lequel on migrait une partie des contenus et où l'on répliquait les logiques du précèdent site. Depuis Drupal 8.9, les transitions vers la version majeure supérieure devraient maintenant pouvoir s’effectuer plus en douceur, sans forcément tout avoir à refaire à chaque fois. 

Toutefois, ne pas oublier les « site builders »

Toutes ces évolutions revêtent toutefois un effet pervers : celui de laisser les moins techniques des créateurs de site sur le bas-côté. Cette catégorie d'utilisateurs nommée « site builders » dans les keynotes fait pourtant partie des utilisateurs historiques qui ont  activement contribué à l’évolution de Drupal. Il est donc important de ne pas les délaisser !  L'usage obligatoire de Composer, par exemple, n'est pas évident pour un non-technique. Plusieurs initiatives ont donc été lancées pour contrebalancer ces difficultés, notamment via un store de modules, appelé  « project browser » et directement intégré dans l'administration du site Drupal. Cette logique se retrouve entre autres dans Wordpress. 

Drupal n'a donc pas fini d'évoluer,  je pense notamment au gros travail de mise à plat de tout le workflow de contribution qui amènera encore plus de personnes à enrichir Drupal, renforçant par-là ses fonctionnalités comme sa sécurité. 

D'ailleurs, has been, ce n'est pas un peu daté comme expression ? 

Drupal, un écosytème complet ?