Drupal est un système de gestion de contenu (CMS). Il est surtout conçu pour les développeurs. Le but de ce tutoriel est d'expliquer comment Drupal peut être étendu de nombreuses façons et pour de nombreux objectifs. À cette fin, la version que nous utiliserons sera la dernière sortie : Drupal 9. Néanmoins, un grande partie de ce que nous apprendrons est déjà valable pour les versions 8.8 et ultérieures.

Dans ce cours, nous couvrirons un large éventail de sujets de développement. Nous verrons comment créer un module Drupal 9, et au fil des chapitres, nous couvrirons de nombreux concepts et conseils qui vous aideront à construire ce dont vous avez besoin. Le but n'est pas seulement d'expliquer comment les choses fonctionnent, mais aussi de passer en revue quelques exemples afin de les démontrer.

Ce chapitre présente la terminologie, les outils et les processus de développement de modules dans Drupal 9. Alors que les chapitres suivants se concentrent sur le code, ce chapitre se concentre sur les concepts. Nous parlerons de l'architecture de Drupal et de la façon dont vous pouvez vous connecter à Drupal  pour l'étendre afin d'accomplir de nouvelles tâches.

Voici les principaux sujets que nous aborderons dans ce chapitre :

  •     Une introduction au développement de Drupal
  •     Comment sommes-nous arrivés à Drupal 9 ?
  •     L'architecture de Drupal 9
  •     Les principaux sous-systèmes de Drupal
  •     Outils de développement dans Drupal

À la fin de ce chapitre, vous comprendrez les aspects architecturaux de Drupal et serez prêt à commencer à écrire du code.

Présentation de Drupal (pour les développeurs)

Drupal a traditionnellement toutes les fonctions standard d'un système de gestion de contenu basé sur le web :

  • Les visiteurs peuvent consulter les informations publiées sur le site, naviguer dans les menus, les pages, etc.
  • Les utilisateurs peuvent créer des comptes et laisser des commentaires.
  • Les administrateurs peuvent gérer la configuration du site et contrôler les autorisations des utilisateurs.
  • Les éditeurs peuvent créer, prévisualiser, puis publier le contenu lorsqu'il est prêt.
  • Le contenu peut être syndiqué au format RSS, afin que les lecteurs de flux puissent recevoir les nouveaux articles au fur et à mesure de leur publication.
  • Grâce à plusieurs thèmes intégrés, même l'aspect et la convivialité du site peuvent être facilement modifiés.

Cependant, Drupal 8 a amélioré ces thèmes et a introduit des fonctionnalités plus puissantes. Par exemple, le support multilingue avancé, la modération de contenu, la construction de la mise en page, l'API REST et de nombreuses autres fonctionnalités sont maintenant disponibles dès le départ. Et oui, je parlais bien de Drupal 8 car tout cela a commencé avec cette version et se poursuit avec l'actuel Drupal 9.

Comment sommes-nous arrivés à Drupal 9 ?

Drupal 9 n'est pas une étape importante dans l'évolution de Drupal.. Il l'est, mais pas à une échelle comparable à celle de la sortie de Drupal 8.0 qui a constitué une totale rupture technologique avec drupal 7. Drupal 9 est plutôt la preuve que certaines décisions ont été prises avec sagesse lorsque le moment est venu de changer le cycle de sortie des versions à laquelle Drupal était habitué.

En matière de versionnement sémantique, les versions mineures signifient que de nouvelles fonctionnalités peuvent être ajoutées à condition que la rétrocompatibilité soit assurée sur toutes les API existantes. Cela signifie que même si dans la version 8.5 vous réalisez qu'une API publique doit être modifiée, vous devez vous assurer que dans la version 8.6, elle continue à fonctionner. Dans un état déprécié, bien sûr, mais toujours compatible. La plupart du temps, ces API sont simplement déléguées aux nouvelles API. Mais au fil du temps, la base de code se remplit de code obsolète qui ne devrait plus être utilisé. Voilà le rôle des versions majeures, comme Drupal 9.

Les versions majeures permettent de supprimer tout le code obsolète et demandent aux développeurs et aux utilisateurs du logiciel de s'assurer qu'ils sont compatibles avec toutes les nouvelles API et elles se débarrassent des anciennes. C'est donc exactement ce que fait Drupal 9 : supprimer tout le code déprécié de la version 8.9 et l'appeler Drupal 9. Les deux seront identiques à bien des égards.

Mais pourquoi maintenant ? Pourquoi pas dans 4 ans ? Ou dans 5 ans ? Outre la base de code croissante remplie de codes inutiles et la difficulté croissante de gérer ces dépréciations, Drupal est également confronté au défi de maintenir ses dépendances. Depuis qu'il a commencé à s'appuyer sur d'autres bibliothèques open source, il est également devenu dépendant de leur cycle de vie. Ici, le plus notable est Symfony. Drupal 8 utilise Symfony 3, dont la fin de vie est prévue pour novembre 2021, et donc la fin de vie de Drupal 8 doit coïncider avec cela. La mise à jour vers Symfony 4 signifierait une rupture de la rétrocompatibilité, et une nouvelle version majeure de Drupal est donc également nécessaire. En outre, il existe de nombreuses bibliothèques qui pourraient être mises à jour, comme Twig vers la version 2. Ce qui est également très bien.

Où cela nous mène-t-il ? Tout ce que vous apprendrez dans ce cours sera compatible avec Drupal 9. Beaucoup de choses seront également compatibles avec Drupal 8, surtout les versions ultérieures, et avec de légers ajustements. C'est pourquoi, à l'avenir, je m'abstiendrai de mentionner des versions spécifiques de Drupal, car cela a de moins en moins de sens. Sauf, bien sûr, lorsqu'il devient pertinent d'être précis sur la version.

Développer pour Drupal

Aussi fantastiques que soient ces fonctionnalités, elles ne répondront certainement pas aux besoins de tous les utilisateurs. C'est pourquoi les capacités de Drupal peuvent être facilement étendues grâce à des modules, des thèmes et des profils d'installation. Jetez un coup d'œil au site principal de Drupal (http://drupal.org), et vous y trouverez des milliers de modules qui offrent de nouvelles fonctionnalités et des milliers de thèmes qui transforment l'apparence de l'application ou du site web.

La souplesse d'extension et de transformation de Drupal par le biais des mécanismes de modules et de thèmes a conduit beaucoup de gens à affirmer que Drupal n'est pas seulement un CMS, mais framework de gestion de contenu (CMF), capable d'être ré-outillé en fonction de besoins spécifiques et d'exigences fonctionnelles.

Déterminer si Drupal est à juste titre appelé CMS ou CMF dépasse notre propos ici, mais il est certain que l'atout le plus formidable de Drupal est son extensibilité. Vous souhaitez utiliser un serveur d'annuaire pour l'authentification ? Il existe un module Drupal pour cela. Vous voulez exporter des données vers des fichiers CSV (Comma-Separated Value) ? Il existe plusieurs modules pour cela (en fonction des données que vous voulez exporter). Vous êtes intéressé par le support de Facebook, l'intégration avec Twitter ou l'ajout d'un bouton "Partager" ? Oui, il y a des modules pour ça aussi - tous sont disponibles sur Drupal.org et fournis par des développeurs comme vous.

Vous souhaitez intégrer Drupal à un outil externe ? Il n'y a peut-être pas de module pour cela, mais avec un peu de code, vous pouvez écrire le vôtre. En fait, c'est le sujet de ce cours - vous fournir les connaissances et les outils pour atteindre vos propres objectifs.

En résumé, le but de ce cours est de vous préparer (le plus rapidement possible) au développement du module Drupal 9. Au fil des chapitres, nous aborderons les API et les outils que vous utiliserez pour créer des fonctionnalités Drupal personnalisées, et nous ne nous en tiendrons pas à la théorie. Nous suivrons les conventions de codage de Drupal et utiliserons les modèles de conception de Drupal afin d'illustrer la manière correcte d'écrire du code dans le contexte de développement de Drupal.

Commençons donc par quelques questions préliminaires pour mieux comprendre Drupal.

L'architecture de Drupal 9

Drupal est soumis à une série de bonnes pratiques en ce qui concerne la manière dont il doit être installé. Mais la réalité est qu'elles sont simplement adaptées à des besoins différents. La plus courante, et la plus recommandée, est l'approche basée sur Composer avec le projet Drupal, promu par la communauté ici : https://www.drupal.org/docs/develop/using-composer/starting-a-site-using-drupal-composer-project-templates.

Vous en apprendrer d'avantage sur la façon d'installer Drupal, je n'entrerai donc pas dans les détails ici. Parlons plutôt un peu des technologies qui alimentent (ou sont nécessaires à) Drupal 9.

PHP

Drupal est écrit en PHP.  Comme Drupal est écrit en PHP, ce cours  présentera en grande partie du code écrit en PHP (mais pas que ;)), tout en gardant à l'esprit les pratiques standard de Drupal.

Il est très important de noter que la version minimale de PHP requise pour que Drupal 9 fonctionne (et s'installe via Composer) est la 7.3. Par conséquent, PHP 7.1 n'est plus supporté car il a atteint sa fin de vie en décembre 2019.

Bases de données MySQL

Drupal utilise la puissante bibliothèque PHP Data Objects (PDO) qui est le standard dans PHP 7. Cette bibliothèque est une couche d'abstraction qui permet aux développeurs de prendre en charge de nombreuses bases de données, dont MySQL, PostgreSQL, SQLite et MariaDB.

Les versions minimales des bases de données pour Drupal 9 sont les suivantes :

  • MySQL 5.7.8/MariaDB 10.3.7/Percona Server 5.7.8 ou ultérieur avec PDO et un moteur de stockage primaire compatible avec InnoDB
  • PostgreSQL 10 ou ultérieur
  • SQLite 3.26 ou ultérieur

Serveur web

Apache a longtemps été le serveur web prédominant, mais il n'est en aucun cas le seul serveur. Bien que Drupal ait été écrit à l'origine avec Apache à l'esprit, de nombreux autres serveurs web (y compris IIS, Lighttpd et Nginx) peuvent fire fonctionner Drupal.

Nous n'abordons pas explicitement la couche des serveurs web dans ce cours, principalement parce que le développement nécessite rarement de travailler à ce niveau. Cependant, Drupal attend de la couche serveur web une bonne quantité de traitement, y compris la gestion de la réécriture d'URL.

Les deux serveurs web les plus courants sur lesquels vous utiliserez Drupal sont Apache et Nginx, avec les versions minimales suivantes pour Drupal 9 :

  • Apache 2.4.7 ou ultérieur
  • Nginx 1.1 ou ultérieur

HTML, CSS, et JavaScript

Le format de données Web de facto est le HTML avec des feuilles de style en cascade (CSS). Les composants interactifs côté client sont scriptés avec JavaScript. En tant que développeurs Drupal, nous rencontrerons ces trois technologies dans ce cours. Bien qu'il ne soit pas nécessaire d'être un ninja du JavaScript pour comprendre le code ici, vous vous en sortirez encore mieux si vous êtes à l'aise avec ces trois technologies.

Architecture de Drupal

Dans la section précédente, nous avons présenté les technologies qui font fonctionner Drupal. Cependant, comment s'articulent-elles toutes ensemble ? Comment le code est-il organisé ? Laissez--moi vous donner un aperçu rapide de cette architecture.

Drupal core, modules, et thèmes

D'un point de vue architectural, on peut décomposer Drupal en trois parties : son noyau, ses modules et ses thèmes.

Lorsque nous parlons du noyau de Drupal, nous pouvons l'interpréter de deux façons. Une interprétation plus restrictive consiste à le considérer comme la fonctionnalité couverte par tout le code qu'il contient, à l'exclusion des modules et des thèmes. L'interprétation la plus répandue est celle de la base de code totale qu'il contient (à l'installation).

Bien que cette dernière interprétation soit la plus répandue (notamment parce qu'elle différencie toutes les fonctionnalités contenues dans son installation standard de toutes les autres fournies par les modules et thèmes contribués), il est intéressant de considérer la première également, même si ce n'est que pour une minute. Car ce faisant, nous pouvons distinguer, sur le plan architectural, le code de base des modules et des thèmes qui fournissent diverses fonctionnalités et mises en page. Et pourquoi cette distinction est-elle intéressante ? Parce qu'à la frontière entre les deux entrent en jeu les hooks et les events qui nous permettront également d'injecter des liens vers nos propres fonctionnalités.

Les bibliothèques de base sont composées de code appartenant au projet Drupal et de ceux de la communauté PHP au sens large, que Drupal emprunte sous licence open source. Cette dernière approche était nouvelle dans Drupal 8, s'est poursuivie dans Drupal 9 et a été considérée par beaucoup comme un changement positif vers la sortie de l'écosystème Drupal et l'adoption de bibliothèques, de frameworks issus de communautés externes.

Essentiellement, les bibliothèques de base fournissent les fonctions et les services utilisés dans tout Drupal. Par exemple, les bibliothèques centrales de Drupal fournissent des aides pour l'interaction avec la base de données, la traduction, le nettoyage des données des utilisateurs, la création de formulaires, l'encodage des données, et de nombreux autres utilitaires de ce type.

Les modules (standards et contribués) sont les endroits où la plupart de la logique "business" est encapsulée. S'ils sont activés, ils peuvent fournir des fonctionnalités ou étendre celles qui existent déjà. La plupart des modules de base sont nécessaires et ne peuvent être désactivés en raison de leur importance dans l'installation standard de Drupal. Toutefois, les modules contribués peuvent être installés et désinstallés selon les besoins.

Les thèmes (standards et contribués) sont une partie importante du système de thèmes et sont utilisés par la couche d'affichage. Ils fournissent des modèles HTML dans lesquels le contenu et les données peuvent être affichés à l'utilisateur, ainsi qu'un style CSS et même du JS pour certaines interactions. Les thèmes peuvent étendre d'autres thèmes et peuvent également contenir une certaine logique PHP pour traiter les données avant d'être rendues.

Maintenant que nous avons vu ce que font les bibliothèques, modules et thèmes de base, parlons brièvement des hooks (crochets) et des events 'évènement) pour comprendre comment ils sont tous connectés.

Hooks, plugins, et events

Les hooks sont un concept procédural très typique de Drupal qui permet au noyau et aux modules de Drupal de rassembler des données provenant d'autres modules et thèmes (ou de les exposer). Ce faisant, ces derniers peuvent fournir de nouvelles fonctionnalités ou modifier celles qui existent déjà. C'est la responsabilité du code qui sollicite le hook pour utiliser ce que les implémentations du hook renvoient. Le format de ce que ces dernières doivent renvoyer est généralement décrit dans la documentation du hook.

Concrètement, les hooks fonctionnent en scannant les modules et les thèmes installés, et en recherchant une fonction qui suit un modèle de nommage spécifique (en d'autres termes, une implémentation de hook). Dans la plupart des cas, il s'agit du format suivant : —module_name_hook_name. En outre, il existe également des "alter hooks", dont le mot alter est collé à la fin du nom de la fonction et qui sont utilisés pour modifier les données transmises en référence à l'implémentation du hook. Nous verrons des exemples de hook plus loin dans le cours.

Dans les versions précédentes de Drupal, jusqu'à Drupal 8, les hooks étaient ROI. C'est parce qu'ils permettaient d'ajouter ou d'étendre les fonctionnalités des modules. En tant que tels, ils constituaient l'aspect le plus important de la programmation Drupal. Dans Drupal 8, cependant, bien qu'ils soient toujours importants, ils sont passés au second plan au profit de nouveaux concepts, tels que les plugins et les événements. Il est question de les faire disparaître complètement dans Drupal 10 ou 11. Nous verrons bien...

Depuis Drupal 8, ce sont les plugins qui sont sont rois. Une grande partie de la logique qui était auparavant liée à Drupal par des hooks est maintenant ajoutée par le biais de plugins (à ne pas confondre avec les plugins de WordPress). Les plugins Drupal sont des éléments de fonctionnalité centralisés par un gestionnaire et qui sont utilisés pour certaines tâches et fonctions. Nous verrons plus en détail les plugins et fournirons de nombreux exemples plus tard dans ce cours.

Un troisième point d'extension introduit dans Drupal 8 est le système d'événements. Contrairement aux deux premiers, il n'est pas spécifique à Drupal, mais est en fait  composant de Symfony : EventDispatcher  (http://symfony.com/doc/current/components/event_dispatcher.html). Les événements sont principalement utilisés dans Drupal pour intercepter certaines actions ou flux afin de les arrêter ou de les modifier. De nombreuses tâches de demande de réponse qui étaient traitées par des hooks dans le passé sont maintenant traitées par des événements de dispatching pour vérifier si des modules sont concernés, par exemple, par la livraison de la réponse à l'utilisateur.

Les services et le conteneur d'injection de dépendance

Un autre élément architectural important de Drupal est le composant d'injection de dépendance Symfony (http://symfony.com/doc/current/components/dependency_injection.html), spécifiquement représenté par le services container.

Ce composant est un élément de base de la POO en PHP moderne et, en tant que tel, est devenu un élément fondamental de Drupal depuis la version 8. Il nous permet de créer des services qui peuvent être injectés à différents endroits de notre code afin de gérer certaines tâches fonctionnelles (et souvent interchangeables). En outre, ils peuvent également être utilisés comme point d'extension car le conteneur de services est capable de regrouper des services qui ont des responsabilités très spécifiques et de les utiliser dans un but précis de manière automatique. En d'autres termes, en définissant simplement un service simple, nous pouvons fournir notre propre fonctionnalité ou même modifier la logique existante.

Nous rencontrerons de nombreux services, et nous verrons comment nous pouvons déclarer les nôtres plus tard dans ce cours.

De la requête à la réponse

Maintenant que nous avons dressé la liste des pièces architecturales les plus importantes de Drupal, voyons brièvement comment elles sont utilisées pour répondre aux demandes d'un utilisateur sur un site Drupal. À cette fin, nous allons analyser un exemple simplifié de demande traitée :

  1. Un utilisateur accède à la page http://example.com/node/123 depuis son navigateur.
     
  2. Le navigateur contacte le serveur web à l'adresse suivante example.com et demande la ressource à /node/123.
     
  3. Le serveur web reconnaît que la demande doit être traitée par PHP et démarre (ou contacte) un environnement PHP pour traiter la demande.
     
  4. PHP exécute le fichier du contrôleur frontal de Drupal (index.php), qui crée alors un nouvel objet Request à partir de la ressource qui a été demandée.
     
  5. Le HTTPKernel de Symfony gère cet objet de requête en envoyant un certain nombre d'événements, tels que kernel.request, kernel.controller, kernel.response, et kernel.view.
     
  6. La route qui correspond à cette demande est identifiée par l'événement kernel.request.
     
  7. Le contrôleur de route est identifié, et l'événement kernel.controller  est utilisé pour effectuer toute modification sur le contrôleur responsable, ainsi que pour résoudre les arguments qui doivent lui être transmis. Dans notre cas, cette route est enregistrée par le module Node via le système principal Entity, qui identifie l'ID de l'entité, le charge et construit le balisage HTML (markup) à renvoyer dans le cadre de la réponse..
     
  8. Si le contrôleur (ou le gestionnaire) concerné renvoie autre chose qu'un objet Response, l'événement kernel.view est envoyé pour vérifier s'il existe un code qui peut transformer cet objet en objet Response. Dans la plupart des cas, les contrôleurs renvoient généralement des tableaux de rendu, qui sont transformés en objets Response.
     
  9. Une fois qu'une réponse est créée, le contrôleur frontal la renvoie au navigateur et met fin à la requête.

Dans ce contexte, en tant que développeurs de modules, nous passons la plupart de notre temps à l'intérieur des contrôleurs et des services à essayer de déterminer ce dont nous avons besoin pour retourner la page désirée. Nous nous appuyons ensuite sur Drupal pour transformer notre tableau de rendu en une réponse appropriée à l'utilisateur, mais nous pouvons aussi en retourner un nous-mêmes directement. De plus, le système de thèmes entre en jeu ici, ainsi que le système de blocs, car notre contenu est enveloppé dans un bloc qui est placé dans une région entourée d'autres régions qui contiennent d'autres blocs. Si cela semble compliqué maintenant, ne vous inquiétez pas ; nous allons couvrir en détail tous ces aspects avec des exemples, et cela deviendra clair en un rien de temps.

Les principaux sous-systèmes de Drupal

Dans la section précédente, nous avons jeté un bref coup d'œil à l'architecture de Drupal. Nous allons maintenant affiner un peu notre perspective. Nous allons passer en revue les principaux sous-systèmes que Drupal a à offrir.

Routing

Tout commence par une route, n'est-ce pas ? La plupart des interactions avec un site web Drupal commencent par l'accès d'un utilisateur (ou d'un système) à un certain chemin (ou ressource). Cela se traduit par une route, qui relie cette ressource à un flux qui (espérons-le) renvoie une réponse, ou du moins un échec gracieux.

Le système de routage est un changement majeur par rapport à ce qu'il était dans les versions antérieures à 8. Dans Drupal 7 et avant, le système de routage était très spécifique à Drupal (un drupalisme, si vous voulez). Beaucoup d'entre nous se souviennent de hook_menu comme un hook de base que chaque développeur Drupal devait très bien connaître. Tout cela a été abandonné depuis Drupal 8 au profit du composant Routing de Symfony (http://symfony.com/doc/current/components/routing.html). Par ailleurs, puisque j'ai mentionné hook_menu, je mentionnerai également que ses autres fonctions principales ont également été reprises par d'autres sous-systèmes, tels que les plugins.

Au chapitre 2, Créez votre premier module, nous verrons comment définir notre propre route et le faire correspondre à un contrôleur qui rendra notre page. Nous aborderons quelques-unes des options de roting les plus importantes et examinerons comment nous pouvons contrôler l'accès à ces routes.

Entités

Progressivement, les entités sont devenues un moyen très puissant de modéliser les données et le contenu dans Drupal. Le type d'entité le plus célèbre a toujours été le nœud (node), et il a été historiquement la pierre angulaire du stockage et de l'affichage du contenu. Depuis Drupal 8, l'ensemble du système d'entités a été remanié pour rendre tout autre type d'entité potentiellement tout aussi important. Ils ont été mis au premier plan et ont été correctement connectés aux autres systèmes.

Tous les types d'entités peuvent avoir plusieurs bundles, qui sont des variations différentes du même type d'entité et peuvent avoir des champs différents (tout en partageant certains champs de base).

Le noyau Drupal est toujours livré avec le type d'entité Node, avec quelques bundles tels que Basic Page et Article dans son profil d'installation standard. De plus, il est livré avec quelques autres types d'entités, comme User, Comment, File, etc. Et la création de votre propre type d'entité est devenue beaucoup plus standardisée par rapport à Drupal 7, par exemple.

Mais ce ne sont pas les seuls types d'entités que nous avons. Les exemples susmentionnés sont tous des types d'entités de contenu. Drupal 8, cependant, a également introduit les types d'entités de configuration. Les premiers sont destinés à la modélisation du contenu, mais en réalité, ils sont destinés à tout ce qui contient des données qui peuvent être stockées dans la base de données et qui sont spécifiques à cet environnement. Ils ne sont cependant pas utilisés pour le stockage de la configuration. Les utilisateurs et le contenu sont de bons exemples, car ils n'ont pas besoin d'être (généralement) déployables d'un environnement à l'autre. Ces derniers, en revanche, sont des éléments de configuration exportables, dont il peut y en avoir plusieurs. Par exemple, un ensemble d'entités de contenu est un bon exemple car il peut y avoir plus d'un ensemble pour un certain type d'entité de contenu ; ils contiennent des métadonnées et des informations qui peuvent varier d'un ensemble à l'autre et doivent être déployés sur tous les environnements. C'est-à-dire qu'elles sont fondamentales pour le bon fonctionnement du site.

La compréhension du système d'entités est indispensable pour faire du développement dans Drupal car elle fournit un moyen puissant de modéliser des données et des contenus personnalisés.

Maintenant que nous avons une idée de ce que sont les entités, examinons comment les données sont réellement stockées sur ces entités.

Fields

J'ai fait allusion dans la section précédente à la façon dont certains groupes d'entités peuvent avoir des champs différents. Cela signifie que chaque ensemble de types d'entités peut avoir un nombre quelconque de champs qui sont responsables de la conservation des données. En outre, chaque type d'entité peut lui-même avoir des champs pour le stockage des données. D'accord, mais quoi ? Décomposons cela.

Il y a deux types de champs dans les champs de base Drupal et les champs configurables. Les premiers sont des champs qui sont définis dans le code pour chaque type d'entité, alors que les seconds sont généralement créés et configurés dans l'interface utilisateur et attachés à un bundle de ce type d'entité (et exportés via la configuration).

Les champs peuvent également être de types multiples, en fonction des données qu'ils stockent. Vous pouvez avoir des champs de type chaîne (ou texte), des champs numériques, des champs de type date, des champs de type courriel, etc. En tant que développeurs, nous pouvons créer nos propres types de champs si les champs existants ne sont pas assez pertinents pour nos données.

Dans ce cours, nous verrons comment nous pouvons définir des champs de base sur un certain type d'entité et créer notre propre type de champ avec son propre widget d'entrée de données et son propre formateur de sortie. Les constructeurs de sites peuvent ensuite utiliser ce type de champ sur n'importe quel type d'entité.

Menus

Tout site a besoin d'une navigation, n'est-ce pas ? Drupal ne se contente pas de maintenir le contenu, mais fournit également des outils pour l'organisation du site lui-même. C'est-à-dire qu'il conserve une structure du contenu.

La principale façon dont il le fait est le sous-système de menu. Celui-ci fournit des API pour générer, récupérer et modifier les éléments qui décrivent la structure du site. En langage courant, il gère les menus de navigation du système.

Les menus sont hiérarchiques, c'est-à-dire qu'ils ont une structure arborescente. Un élément de menu peut avoir plusieurs enfants, chacun d'eux pouvant avoir ses propres enfants, et ainsi de suite. De cette façon, nous pouvons utiliser le système de menus pour structurer notre site en sections et sous-sections.

Dans ce cours, nous verrons comment nous pouvons travailler de manière programmatique avec des menus et des liens de menu.

Vues

Lister le contenu et les données est toujours une capacité importante que les CMS convoitent ; et c'est ce que fait Views dans Drupal. Et il le fait bien.

L'objectif du module Views est d'exposer les données et le contenu de manière à permettre la création de listes configurables. Il comprend des éléments tels que des filtres, des tris, des options d'affichage et de nombreuses autres fonctionnalités. En tant que développeurs, nous avons souvent besoin d'écrire notre propre champ ou plugin de filtrage pour travailler avec Views ou exposer des données provenant de nos entités personnalisées ou de sources de données externes.

Views est lié à l'architecture générale et utilisé pour la plupart des pages de liste (en particulier les pages d'administration) fournies par le noyau de Drupal. Bien qu'il s'agisse d'un outil très orienté vers la création de sites, dans ce cours, nous examinerons comment nous pouvons créer des plugins qui étendent ses capacités pour offrir encore plus aux créateurs de sites.

Formulaires

À moins que votre site ne comporte trois pages et cinq paragraphes de texte, il est très probable que vous deviez saisir les informations fournies par l'utilisateur au moyen d'un formulaire quelconque. De plus, si vous avez codé des applications PHP, vous savez que les formulaires ont toujours été une source de difficultés pour la présentation et le traitement sûrs et efficaces des données soumises. Dès que vous utilisez un framework PHP tel que Symfony ou Laravel, vous constaterez qu'une API est en place pour vous décharger d'une grande partie de cette charge.

Il en va de même avec Drupal et sa puissante API de formulaire. Historiquement, il s'agit d'une grande abstraction par rapport à la nécessité de produire vos propres éléments de formulaire et de traiter les valeurs affichées. Elle vous permet de définir votre propre définition de formulaire en POO et de gérer la validation et la soumission de manière logique. Son rendu et son traitement sont pris en charge par Drupal de manière sécurisée, vous n'avez donc pas à vous soucier de tout cela.

Dans ce cours, nous allons rencontrer quelques formulaires et voir comment ils fonctionnent réellement en pratique.

Configuration

L'un des principaux chevaux de bataille des développeurs Drupal (et d'ailleurs des autres CMS populaires) a toujours été la manière dont la configuration est gérée et déployée d'un environnement à l'autre. Drupal 7 stockait la plupart de sa configuration dans la base de données, de sorte que les développeurs ont dû concocter diverses solutions pour la faire progresser au fur et à mesure du développement.

Depuis Drupal 8, de grands progrès ont été réalisés à cet égard avec l'introduction d'un système de configuration centralisé. Bien qu'il stocke toute la configuration dans la base de données, il permet de l'exporter dans des fichiers YAML (et de la réimporter ensuite). Ainsi, d'un point de vue développement, nous avons une bien meilleure expérience si certaines caractéristiques dépendent de la configuration (par exemple, un nouveau champ). Ce système est continuellement amélioré, de puissantes étapes ayant été franchies dans les dernières versions de Drupal 8.

La configuration est également de deux types - simple et complexe (entités de configuration que nous avons notées dans la section Entités). La différence entre les deux est que la configuration simple est toujours singulière. En d'autres termes, il n'y a qu'une seule instance d'elle-même. Par exemple, le nom du site et l'adresse électronique sont stockés à l'intérieur d'un tel élément de configuration. Vous ne vous attendez pas à avoir besoin de plus d'une instance de ces deux éléments de valeur. Cependant, dans le cas d'une configuration complexe, vous le feriez. Par exemple, une définition de vue est une entité de configuration complexe car elle suit un certain schéma et nous pouvons avoir plusieurs définitions de vue. C'est logique, n'est-ce pas ?

Plugins

Les plugins sont une solution élégante à un problème important : l'encapsulation des fonctionnalités. D'emblée, il ne faut pas les confondre avec des choses comme les plugins WordPress, qui s'apparentent davantage à des modules Drupal. Il faut plutôt considérer les plugins comme des composants de code réutilisables qui peuvent être utilisés et gérés par un système central. En général, ils sont utilisés lorsqu'un système gère une tâche d'une certaine manière (plugin A) mais permet à d'autres modules de fournir différentes manières de gérer cette tâche (plugin B ou C).

Vous pouvez également considérer les plugins comme des entités opposées : ils ne sont pas utilisés pour le stockage de données, mais pour la fonctionnalité. Au lieu de créer un type de données qui est stocké, vous créez un type de fonctionnalité qui est utilisé. Les deux travaillent généralement main dans la main, surtout lorsqu'il s'agit de manipuler les données de différentes manières.

Un aspect important de leur fonctionnement est la possibilité de les découvrir. La plupart des types de plugins sont découverts via ce qu'on appelle des annotations. Les annotations sont une forme de commentaires DocBlock, empruntés à la bibliothèque Doctrine (http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/annotations.html), par lesquels nous pouvons décrire des classes, des méthodes et même des propriétés avec certaines métadonnées. Ces métadonnées sont ensuite lues pour déterminer ce qu'est cet élément sans qu'il soit nécessaire d'instancier la classe. Dans Drupal, nous utilisons des annotations uniquement au niveau de la classe pour indiquer qu'il s'agit d'une implémentation de plugin avec certaines caractéristiques.

La deuxième méthode de découverte la plus courante pour les plugins est le fichier YAML, dont les liens de menu (comme nous le verrons plus tard dans le cours) sont un exemple très répandu. Cependant, pour l'instant, vous devez savoir que les plugins sont très largement utilisés, et nous allons en créer un certain nombre dans ce cours.

Le système de thèmes

La responsabilité de la thématisation d'une donnée quelconque est partagée entre le noyau de Drupal, les modules et les thèmes eux-mêmes. Ainsi, en tant que développeur de modules, il est important de savoir que les modules et les thèmes peuvent tous deux thématiser des données ou du contenu.

Dans ce cours, nous nous concentrerons sur les aspects qui se produisent au niveau des modules. Nous ne nous préoccuperons pas du style, mais nous travaillerons principalement avec les définitions des thèmes et les modèles nécessaires au sein du module. En règle générale, la meilleure pratique consiste à s'assurer que les modules sont en mesure de thématiser leurs données. Si cela est bien fait, les thèmes peuvent alors entrer en jeu pour donner du style à la sortie ou passer outre cette thématisation pour modifier complètement la présentation.

Un changement majeur dans Drupal 8 par rapport aux versions précédentes est le passage au système de template Twig (https://twig.sensiolabs.org/). Cela rend la séparation de la logique d'une présentation beaucoup plus claire et rend le tavail des développeurs frontend beaucoup plus faciles, sans parler de la sécurité. Et avec Drupal 9, la version de Twig a finalement été mise à jour de 1 à 2.

Mise en cache

Le dernier grand sous-système que je vais inclure ici est la couche de caching. Depuis la version 8, Drupal s'est donné beaucoup de mal pour améliorer les performances de construction des pages et de rendu des données. À cette fin, le système de mise en cache est devenu un élément important à prendre en compte chaque fois que nous effectuons des calculs complexes ou lourds ou que nous rendons du contenu.

Du point de vue d'un développeur de modules, le système de mise en cache repose sur deux piliers principaux. Le premier fournit aux développeurs un backend de cache pour stocker les résultats de calculs de données complexes. Celui-ci peut être lu dans les requêtes suivantes pour éviter d'avoir à retraiter cette tâche. Cela va de pair avec l'invalidation du cache qui se produit lorsque quelque chose dans le système change qui nécessiterait de refaire les calculs. Le deuxième pilier est le cache de rendu, qui permet aux développeurs d'envelopper leur sortie avec des métadonnées qui décrivent quand le cache de cette sortie doit être invalidé.

Nous les verrons en action dans un chapitre ultérieur consacré à la mise en cache.

Autres sous-systèmes

Il y a d'autres sous-systèmes dans Drupal 9 d'importance variable. J'ai choisi d'inclure les précédents parce que je les considère comme les plus importants à introduire en amont et surtout du point de vue d'un développeur de modules. Cependant, au fur et à mesure que nous avancerons dans le cours, nous en rencontrerons certainement d'autres.