Drupal 10 : Structure des fichiers d'un module

La structure des modules a évolué avec Drupal 8, le format YAML ayant pris le pas sur le format INI, le .info hérite logiquement de l'appendice .yml. C'est d'ailleurs le seul fichier obligatoire pour faire vivre un module. Ça n'avance pas forcément à grand chose s'il n'y a que ce fichier évidemment mais c'est la répercussion du fait que vous écrirez de moins en moins de hooks (souvent remplacés par des classes, nous y reviendrons).

Les modules ne peuvent plus être dans l’état désactivé, ils sont soit installés soit désinstallés et désinstaller un module retire du système sa configuration.

La conséquence directe de cela est la disparition des hooks suivants :

• hook_modules_preenable()
• hook_enable()
• hook_modules_enabled()
• hook_disable()
• hook_modules_disabled()
• hook_modules_preinstall()

Les fonctions module_enable() et module_disable() filent au musée car elles sont remplacées par une syntaxe à la sauce POO. Pour installer et désinstaller des modules, il faut maintenant utiliser la syntaxe suivante :

// Activation d'un module version D7.
module_enable(array('mymodule'));

// Activation d'un module version D8.
\Drupal::service('module_handler')->install(array('mymodule'), $enable_dependencies);

// Désinstallation d'un module version D7.
module_uninstall(array('mymodule'));

// Désinstallation d'un module version D8.
\Drupal::service('module_handler')->uninstall(array('mymodule'), $enable_dependencies); 

Les modules peuvent définir d’autres informations telles que :

• Des librairies (<module_name>.libraries.yml)
• Des entrées de routeur (<module_name>.routing.yml)
• Des entrées de menu associées à des entrées de routeur (<module_name>.links.<type>.yml)
• Des permissions (<module_name>.permissions.yml)
• Des services (<module_name>.services.yml)

Votre code métier devrait glisser du fichier .module vers des classes. La norme PSR-4 est le standard embrassé pour organiser ces dernières. Elle en permet le chargement automatique, à la demande. Cela engendre l’apparition d’un dossier /src voire d’un dossier /tests afin de respectivement implémenter vos classes de code métier (ex : créer un bloc, créer un nouveau type de champ, widget ou formateur) et vos tests.

On retrouvera aussi de manière régulière les répertoires /config/install et /config/optional qui permettent de fournir les fichiers YAML de configuration par défaut de différents composants de Drupal (View mode, Type de contenu, Configuration, etc.).
Le dossier install contient les éléments qui seront obligatoirement utilisés par votre module, le dossier optional quant à lui contient les configurations utilisables par d'autres modules. Exemple : vous développez un module générique qui peut s'interfacer avec Views. Vous ne savez pas si Views sera utilisé sur le site, vous ne voulez donc pas ajouter une dépendance sur ce module dans le fichier .info.yml mais vous voulez tout de même fournir une vue le cas échéant. Dans ce scénario, il vous suffit alors de placer l'export de votre vue dans le dossier /config/optional et si un utilisateur installe Views sur son site, votre vue sera visible sans action supplémentaire de sa part.
Un dossier /config/schema/ peut également exister, il contient (entre autres) la description de la structure des données lorsqu'elles sont exportées via l'API de configuration.