Il est rare dans la vie d’un développeur de se retrouver face à une évolution majeure de sa technologie de prédilection et pourtant n’avoir que peu de choses à dire dessus.

Pourtant, l’équipe core Drupal nous avait prévenu : " The big deal about Drupal 9 is... That it should not be a big deal ", le ton était donné.

Bien loin des hurlements de panique et des développeurs de la communauté prostrés dans les coins à réapprendre à programmer, ce changement de version s’annonce pour la première fois dans la vie de Drupal, "sans douleur aucune".

Pas de nouvelle logique de développement à apprendre, pas de refonte massive des API, pas de nouveau paradigme ou de comportement du core à apprendre. Rien ! Mais alors ? Pourquoi parler d’un tel non événement ?

L’évolution de Drupal au fil des années

Drupal 6, c’était la voiture à pied. Si vous savez programmer en PHP, vous savez utiliser Drupal.

Drupal 7, c’était le tricycle. La position semble moins confortable, l’engin plus technique, mais le PHP suffit pour 80% des actions. Par contre, si l’on creuse et essaye de comprendre l’API un monde nouveau s’ouvre à nous.

Drupal 8, c’est le vélo avec des petites roulettes. En l’utilisant à minima, on retrouve des habitudes, les fragments les plus utilisés de l’API. Par contre, lorsque l’on prend de la vitesse, habitué au tricycle, vous tombez, encore et encore. Puis on réapprend à faire, et on découvre la puissance de la nouvelle conception et des services/classes qui la composent.

Drupal 9, c’est le même vélo, on a juste retiré les petites roulettes.

Drupal 9 semble donc être une version peaufinée de son prédécesseur Drupal 8 qui était, lui, une révolution.

La révolution Drupal 8

Drupal 8 consiste en une réécriture complète du core Drupal sur un socle Symfony 3. Cette réécriture avait plusieurs buts affichés :

  • Sortir d’un modèle PHP old-school tout en tableaux de tableaux,

  • S’orienter vers une plus grande séparation entre contenus et contenant,

  • Ne pas réinventer la roue et se baser sur des éléments techniques robustes et éprouvés,

Néanmoins, ce renversement important des codes a bousculé les habitudes de la communauté.

L'utilisation de Symfony comme base du Core Drupal 8 a bousculé la communauté

La communauté Drupal s’est fondée sur un grand nombre de développeurs PHP “plus ou moins autodidactes”. Forcer ces derniers à maîtriser des paradigmes de programmation hérités de Symfony, sans autre alternative, c’était prendre le risque d’en voir une grande partie partir ou forker le projet (ce qui s’est produit : Backdrop CMS).

Pour tenter de maîtriser cette fuite en avant, il a été décidé d’assurer un minimum de “compatibilités des API” entre Drupal 7 et 8.

Une Adaptation obligatoire pour les éditeurs de modules

Bien que la réécriture du coeur Drupal soit une belle prouesse, cette action a obligé la communauté à préparer la migration des modules très utilisés, voire essentiels à tout site Drupal. Les équipes en charge du coeur ont encouragé la formation “d’initiatives” afin de permettre à la communauté de s’organiser et permettre l’ajout de ces modules “essentiels” au coeur. C’est ainsi qu’un certain nombre d’entre elles ont vu le jour et ont avancé en parallèle de la réécriture du coeur.

Parmi ces modules & fonctionnalités se trouvent : le multilingue, les médias, le front HTML5, l’intégration du module Views, les Workflows, la gestion de la configuration (CMI),...

Alors que certaines initiatives ont touché au but rapidement au début de Drupal 8, d’autres ont eu besoin de plus de temps pour arriver à maturité.

La stabilisation

Au vu de l’inquiétude causée par cette révolution, il a été rapidement décidé, qu’une solution permettant la montée en compétence de la communauté serait de garder un certain nombre d’éléments d’API communs entre Drupal 7 et 8.

Cela est d’autant plus évident quand on remarque que la quasi intégralité des éléments importés de Drupal 7 sont des fonctions “utilitaires” très utilisées, sans réel impact fonctionnel.

Par exemple :

  • t() qui permet d’indiquer à Drupal qu’une chaîne de textes doit être traduite

  • l() qui permet de créer des liens à partir d’un texte et d’une URL

  • drupal_render qui permet de préparer des éléments pour l’affichage

  • node_load qui permet de charger un contenu

  • drupal_set_message qui permet d’afficher un message

Les premières mises à jour de Drupal 8 (jusqu’à la 8.4) les développements du core Drupal ont été tournés vers une stabilisation des initiatives ajoutées (CMI, multilingue) ainsi qu’à la réécriture des éléments d’API importés de Drupal 7 en “mode” Drupal 8.

Drupal 8 est sur les rails, mais il souffre du manque de migration des modules de la communauté.

Ainsi au fur et à mesure des mises à jour des version de Drupal 8, ces fonctions ont vu leur code réécrit afin d’utiliser les éléments (services/classes) propres à Drupal 8 sans que cela n'ait d’impact sur le code existant. Le seul ajout a été de déclarer ces fonctions comme “obsolètes” et en invitant les développeurs à ne plus les utiliser directement, mais à utiliser le code adapté dans Drupal 8.

La maturité

La deuxième “période” Drupal 8 (depuis la 8.5) correspond elle à une maturité technique et à une agrégation fonctionnelle.

Comme évoqué précédemment, le développement du coeur de Drupal 8 s’est retrouvé suivi de plusieurs “initiatives” ayant pour objectif d’intégrer des fonctionnalité importantes et/ou complexes dans Drupal. Alors que certaines initiative ont touché au but rapidement au début de Drupal 8, d’autres ont eu besoin de plus de temps pour arriver à maturité.

L'agrégation fonctionnelle a continué avec les versions mineures de Drupal 8, jusqu’à la 8.9.

On pourra citer, par exemple :

  • Média arrivé en 8.5 et stabilisé en 8.6

  • Workflows stabilisés en 8.7

  • Layout qui permet de gérer la construction des pages, stabilisé en 8.9

L'intermède 9.0

Deux axes sont à rappeler pour Drupal 9 :

  • Il conviendra de différencier la version 9.0 et les autres versions de Drupal 9

  • Ne pas s’attendre à des surprises

Comme dit précédemment, la version Drupal 0.0 correspond à “retirer les roues du vélo” :

Tous les éléments d’API déclarés comme “obsolètes” car hérités des versions précédentes de Drupal et qui ont trouvé une nouvelle forme dans la nouvelle architecture technique ont simplement été supprimés du code.

Il n’est bien sûr pas question de supprimer des fonctionnalités techniques mais bien de “supprimer l’enveloppe autour de la carte postale”.

Si l’on reprend les exemples :

  • Link::fromTextAndUrl($text, $url) remplace l()

  • \Drupal::service(‘renderer’)->render() remplace drupal_render()

  • \Drupal\node\Entity\Node::load() remplace node_load

  • \Drupal\Core\Messenger\MessengerInterface::addMessage() remplace drupal_set_message()

On vous l’a dit : " The big deal about Drupal 9 is... That it should not be a big deal "

Il y a tout de même quelques évolutions techniques :

  • Les éléments symfony passent de la version 3 à la 4.4

  • Le templating passe de Twig 1 à Twig 2

  • L’obligation d'utiliser PHP dans une version 7.3+ et la version 10 de Drush.

Et après ?

Après, Drupal continuera son chemin. Tous les 6 mois, une nouvelle version mineure de Drupal 9 sortira environ un mois après la release de Symfony associée.

Si l’on veut vraiment garder une image du passage de Drupal 8 à Drupal 9, il faudrait voir Drupal 8.9 comment l’entrée d’une gare, et Drupal 9.0 comme la sortie. Le train n’a pas changé de rails, et continue son chemin. Nous espérons voir arriver de nouvelles fonctionnalités telles que :

  • Le positionnement des champs configurables dans les layouts

  • La seconde mouture de la CMI dont la première n’a pas donné entière satisfaction

  • Une meilleure intégration entre Drupal et Composer dans le but de mettre en place des mises-à-jour automatisées (rolling-update)

  • Un nouveau thème par défaut

(source : https://www.drupal.org/about/strategic-initiatives#drupal-9)

Et Drupal 10 ?

En théorie Drupal 10 sortira courant 2022 avec une nouvelle version de Symfony.

Conclusion

Une dernière note importante, le suivi des mises à jour de sécurité de Drupal 8 se finira en fin 2021. Drupal 8.9 étant la dernière version de la branche 8, aucune des nouvelles fonctionnalités ajoutées à Drupal 9 ne sera retroportée.

Pour conclure sur les prochaines évolutions, la version 8.9 de Drupal est la dernière version de la branche 8 et a comme alter-égo la version drupal 9.0. La version 9.1 sera l’alter-égo d’une 8.10 qui n’existera pas, et ainsi de suite.

Vous avez un projet ? Concrétisons vos idées.