Introduction

Kevin Laland est mainteneur de FillPDF et indique le chemin suivi lors de la refonte de son module en Drupal 8, ainsi que quelques pièges à éviter. Je vous invite à consulter l'ensemble de sa présentation.

TOUT a changé

Ce n'est pas complètement vrai, cependant une grande partie du cœur a effectivement été réécrite. La courbe d'apprentissage s'en ressent, cependant, l'ensemble dégage une plus grande cohérence, et il y a finalement moins de "magie" dans le système. Ainsi, les "design patterns" utilisés dans le cœur le sont de façon relativement identique sur l'ensemble du cœur.

Le port d'un module en Drupal 8 repose plus sur un refactoring / une réécriture du code Drupal 7 que sur un simple port.

Pour bien commencer

Contrairement aux versions précédentes, Kevin déconseille l'utilisation de la page Converting 7.x modules to 8.x. Les informations de cette page sont apparemment complètement obsolètes. Il conseille de plutôt se concentrer sur les "Change records", eux plutôt complets (attention, il y en a un certain nombre), et ce même si les syntaxes d'exemples de code utilisées ne sont pas toujours les meilleurs ou les plus réutilisables.

Enfin, il recommande comme points de départs :

• l'utilisation d'un IDE, qui vous aidera bien pour l'intégration des annotations et le respect des design patterns ;
• l'utilisation du module Drupal Module Upgrader, comme point de départ de votre code ;
• de commencer par les choses simples (permissions, formulaire de configuration) pour ensuite complexifier petit à petit le code impacté.

La première étape

D'abord, le principal, faire fonctionner votre module. Pour cela, simplement commencer par convertir votre module.info en module.info.yml en adaptant simplement la syntaxe.

Les nouvelles APIs

Le "routing system"

Successeur du hook_menu(), les routes sont désormais définies dans le .info.yml du module. Attention, les paramètres de la route varient selon le type de composant concerné (un formulaire, un formulaire d'entité ou un controleur auront donc des déclarations légèrement différentes).

La Form API

Cette API très utilisée dans Drupal n'a pas tant changée que ça en Drupal 8, rajoutant essentiellement une enveloppe objet autour de formulaire qui sont toujours des Render Arrays (un formulaire est maintenant défini en utilisant la fonction buildForm() d'une classe). Cependant, $form_state est désormais un objet, comprenant notamment les fonctions getValue(), setRedirect() ou encore setError(), amenant la encore un peu de cohérence à l'ensemble.

La configuration API

En remplacement des habituelles variable_get() et variable_set(), on utilise désormais la Configuration API, qui dispose de 2 méthodes $config->get() et $config->set() sur un objet de configuration. Attention, selon les contextes où se situe votre code, l'objet de configuration peut être en lecture seule, vous empêchant de réaliser une action de modification, la lecture de la documentation est donc conseillée. ;-)

Les entités

La finition du système d'entités dans le cœur (détaillé dans un autre article) permet d'envisager beaucoup plus sereinement d'utiliser des entités pour toute donnée à stocker en base, et donc de ne plus maintenir des tables personnalisés et des db_select() pour gérer ses données, l'EntityAPI est là pour ça. (Pour définir une entité minimale, il suffit d'étendre la classe ContentEntityType et d'implémenter baseFieldDefinitions()).

Les bibliothèques

Oubliez les fonctions familières drupal_add_css() / drupal_add_js(), il faut utiliser le .libraries.yml pour déclarer les bibliothèques utilisées et leurs dépendances, et utiliser #attached pour les ajouter aux Render Array (ce qui est déjà une bonne pratique pour les formulaires et les blocks en Drupal 7).

"Views In Core"

Views étant inclus dans le cœur, il est plus facile de créer vos listes dans l'administration du site, il suffit de créer une Views, de l'exporter via l'interface de la Configuration Management Interface, de mettre cette vue dans le répertoire config/install de votre module, et voilà !

Derniers conseils

Il est tout à fait possible aujourd'hui d'obtenir un "module" Drupal qui ne contient plus aucun fichier .module, que cela ne vous arrête pas.

Enfin, n'hésitez pas à suivre le projet Drupal Console qui contient un générateur de code et peut être, en complément de l'IDE, une assistance précieuse lors de votre développement.

Conclusion

Finalement, tout n'est pas si terrible, et avec un peu de méthode, on s'en sort !

L'ensemble des notes et lectures de Kevin est également disponible. Bonne lecture, et surtout, bon code !