BLOG | Drupal Camp : un rendez-vous incontournable !

Industrialiser Drupal dans une grande entreprise : les meilleures pratiques

L’industrialisation, ou l’art de gagner du temps, d'augmenter la qualité de son code, sa couverture de tests, sa sécurité, et donc finalement, son degré de confiance dans des opérations sensibles telles que les mises en production. En 2024, c’est quelque chose qui me semble essentiel. Sur ce sujet, Klee est plutôt bien doté. 
Nos processus de développement, les outils de développeurs (GitLab, IDE, XDebug, etc.) et les outils intégrés à notre plateforme d’intégration (mesure de qualité du code comme PhpCS, PHPStan, PHPMD, les linters, etc.) nous permettent une bonne industrialisation. 
Cela passe d’abord par des processus bien définis auxquels tous les acteurs du projet participent :

• Des tickets minimalistes à traiter par les développeurs (1 fonctionnalité = 1 ticket !).
• Des DOR/DOD (Definition Of Ready, Definition Of Done).
• Des pré-commits pour vérifier la qualité du code avant envoi au dépôt Git.
• Des Merge Requests qui déclenchent des pipelines : re-vérification de la qualité, tests de non-régression ; puis une relecture par un lead développeur.
• Des tests QA.
• Des scripts pour exécuter les actions les plus courantes sur les environnements de qualification.

Puis, la CI/CD ouvre un champ des possibles suffisamment large pour d’abord générer un livrable à partir des sources (build) et envisager conjointement avec les hébergeurs, un déploiement vers les environnements cibles, 
de la recette usine jusqu’en prod. Le but étant de réduire au maximum le TTM (Time To Market), et que n’importe quelle personne de l’équipe soit capable de déployer. On gagne en temps, les erreurs humaines sont limitées. 

Tout le monde est donc capable de déployer, et il est rare d’avoir de mauvaises surprises une fois le processus rodé. Cette conférence a été complétée par celle de KGaut « une pipeline de déploiement aux petits oignons avec GitLab CI » qui présente de manière plus générique les différentes étapes qu’il est possible d’exécuter dans une CI : backup, vérification de l’intégrité de l’environnement cible…À noter que ces conférences ne traitent pas de sujets avancés comme l’organisation des fichiers YAML et l’ordonnancement de la chaîne et ses tâches qui peuvent rapidement être complexes sur un gros projet.

Table ronde : les secrets d'une usine à sites réussie

Le sujet de l’industrialisation a aussi été abordé dans la table ronde sur les usines à sites. Une table ronde qui a été particulièrement intéressante car plusieurs profils étaient présents pour échanger sur le sujet : utilisateurs, chefs de projet, développeurs, etc.Tous n’ont pas la même vision de ce qu’est une usine à sites et selon l’auteur de la demande (DSI, DIRCOM, etc.), le besoin n’est pas le même non plus (rapidité de déploiement, rationalisation des technos, etc.), mais on peut définir ce terme par la possibilité de générer et déployer des sites standardisés en toute autonomie (sans intervention technique). D’ailleurs d’un point de vue technique, plusieurs solutions peuvent répondre à ce besoin, avec chacune leurs avantages et leurs inconvénients : multi-site, domain, Acquia Site Factory, micro_site,… 

Tous les participants de cette table ronde ont été unanimes, le besoin doit être au centre des décisions ! 
Il est plus que nécessaire de bien l’analyser (contenus partagés, création des sites par l’utilisateur, rapidité de déploiement, volumétrie de sites, etc.) pour ensuite proposer la solution la mieux adaptée. 

Les experts techniques ont pour ça un rôle crucial. Ils doivent analyser, challenger et expliquer le choix d’une solution d’usine à sites plutôt qu’une autre ; voire requalifier le besoin en proposant des solutions moins complexes. L’idée consiste à proposer une solution adaptée au besoin afin que l’« usine à sites » ne se transforme pas en « usine à gaz », laquelle serait compliquée à maintenir pour toutes les parties (« enfer des mises à jour »).

Sites écoconçus et accessibles avec Drupal : l'exemple des Bretillien.nes

En 2024, l’un des sujets importants est le climat et l’impact des solutions que nous développons n’est pas négligeable. Le RGESN est là pour œuvrer en faveur d’un numérique public écoresponsable. Le retour d’expérience sur le développement du site du département de l’Ille-et-Vilaine en est un exemple d’implémentation. 

Si la technique a un rôle à jouer, il en demeure d’après ce REX que ce sont tous les acteurs de la chaîne qu’il faut mobiliser (direction, utilisateur, développeur, etc.). La clé du succès est de les impliquer dès le début du projet, d’intégrer la démarche dans les process existants (gestion de projet, de qualité etc.) afin d’ancrer de manière durable la démarche et de profiter de ce qui fonctionne déjà.

Pour mesurer l’impact environnemental et voir son évolution tout au long du projet, il convient de se baser sur le RGESN et s’outiller avec des outils comme l’éco-index web, ou éco-code afin de disposer d’indicateurs reconnus. Une fois les mesures obtenues, les résultats doivent être valorisés et partagés avec l’ensemble de l’équipe afin de renforcer l’engagement sur le sujet. Pour ce site, c’est notamment toute la ligne éditoriale qui a été revue pour simplifier les contenus (page d’accueil moins verbeuse, contenus plus épurés).

Des études ont été menées pour savoir quoi conserver, par exemple sur la page d’accueil où peu d’utilisateurs scrollaient. J’ai été surpris par le choix d’intégration des médias externes. 

Un simple lien vers un podcast ou une image avec un lien ouvrant une vidéo / carte interactive, plutôt qu’une intégration embarquée n’est-elle pas suffisante ? Après tout, combien de médias sont chargés dans une page alors qu’ils ne sont pas consultés ? En plus de ça, si on ajoute un message de consentement pour les cookies, la solution devient respectueuse du RGPD sans nécessité d’intégrer une librairie de gestion des cookies comme tarte au citron, la boucle est bouclée ! Côté technique, il faut aussi se questionner davantage : la fonctionnalité est-elle vraiment nécessaire, possibilité de simplification ? Est-ce que le module que je « dois » installer n’en fait-il pas trop ? 
Ce sont finalement des questions évidentes que l’on doit tous se poser.

UI et Design Systems : améliorer l'intégration Front-End avec Drupal

Un thème majeur de ce DrupalCamp est l’impact qu’ont l’Atomic Design, les « design systems » / UI Kit / styleguide et les Single Directory Components sur le développement « Front » et l’intégration HTML.

Maîtriser l'art du Design System dans Drupal : méthodes et outils

L’atomic Design dans Drupal, c’est rendre les thèmes plus performants, réactifs et surtout plus faciles à maintenir.
Les points suivants ont été présentés par Waren :

• Découpage en suivant l’atomic design, utilisation d’un UI KIT, de tokens, de « Block, Element, Modifier (BEM) » et d’une architecture 5-1 (vs 7-1, dossiers pages et thèmes)
• Comparaison de la différence entre variables CSS et SASS.

Single directory components : implémentation et avantages

Ou SDC pour les intimes est une implémentation de l’Atomic Design dans le core Drupal. 
Cela permet de créer des composants indépendants embarquant le code HTML, le CSS et le JS nécessaire à son bon fonctionnement, à l’image de ce que font la plupart des frameworks JS. En résumé, cela sert à créer des briques réutilisables que l’on peut imbriquer les unes dans les autres. L’implémentation de SDC est simple, dans un module ou un thème, il suffit d’un répertoire « components » qui contient une arborescence libre pour structurer les composants. Chaque composant doit avoir son répertoire (nom unique !) propre contenant :

• Un fichier yml de déclaration,
• Un fichier twig,
• Les assets (images etc.) dans un répertoire assets,
• Un fichier js,...

Container Query : la révolution du Responsive Design

Nouveauté 2023/2024, c’est un complément des media queries qui s’applique au niveau des éléments. 
Elles réagissent principalement sur les dimensions de ces derniers et non sur celles du viewport. 
Cela permet de rendre d’avoir des règles de « responsive » indépendantes, qui ne sont donc liées qu’au composant et qui le rendent encore plus portable.

Accessibilité Web : optimiser le back-office pour tous les utilisateurs

Présentation de l’accessibilité, des outils utilisés pour accéder à un site interne quand on est en situation de handicap. Drupal peut être accessible, mais cela demande un travail minutieux sur le code HTML généré par le thème : présentation des principales balises HTML à adapter. https://drive.google.com/file/d/12Y4lols0PuOocY8BcUu5ZweviKhhsI4Q/view?usp=sharing

Les deux Render API de Drupal : fonctionnalités et complexités

Pierre Dureau, auteur du module ui_suite, nous a présenté le fonctionnement des deux API de rendu dans Drupal après quelques rappels sur les render arrays, tableaux chers à Drupal (et encore on ne parle pas de la Form API) ! Simples à utiliser mais compliquées à comprendre ! Il y a en effet 3 types :

• Les éléments (au nombre de 34),
• Les Hooks thème,
• Les cas spéciaux, dont certains directement rendus (link, inline template) et d’autres wrapper vers des thèmes (« #theme » ou « hook_theme »). Le schéma du processus de rendu documenté (sur la page suivante https://www.drupal.org/docs/8/api/render-api/the-drupal-8-render-pipeline) illustre parfaitement cette complexité !

Améliorer la génération de vignettes : le module crop & media

DrDam nous a présenté son module destiné à améliorer la génération de vignettes. Les modules existants (crop, styles d’images) fournis par le core et la communauté sont finalement assez limités si l’on souhaite des rendus de zones particulières d’une image dans des contextes différents. Avec le standard et le module Crop, c’est possible, mais il faudra réuploader l’image pour chaque contexte ! Et avec l’utilisation du module média, cela complexifie encore plus la chose. La suite Media contextual CROP Collection propose donc tous les outils nécessaires pour cela en gardant toute la puissance des styles d’images et de !

Conférences techniques : les nouvelles tendances et outils

Le reste des conférences auxquelles j’ai pu assister étaient plus techniques avec de la diffusion de connaissances. C’était l’occasion de réviser certains sujets et d’apprendre quelques petites choses, en vrac ci-dessous !

ElasticSearch : améliorer l'expérience de recherche utilisateur

Le moteur de recherche fulltext ElasticSearch est un bon composant pour améliorer l’expérience utilisateur d’une recherche. Cette conférence portait sur le fonctionnement interne du moteur : les traitements appliqués lors des processus d’indexation et de recherche (analyzer, tokenizer et filter), le calcul du score de pertinence des résultats via l’algorithme BM25 (de manière simplifiée !) avec les notions de fréquence de terme recherché, de fréquence inverse dans l’ensemble des documents.

Xdebug : l’outil indispensable de débogage pour les développeurs

L’outil indispensable de débogage pour les développeurs ! Si de prime abord Xdebug est compliqué à configurer 
(en fait pas tant que ça quand on connaît les petits trucs ?), c’est un outil puissant qui simplifie la vie. 
Il permet de :

• Mettre des points d’arrêt dans l’exécution du code PHP (breakpoints),
• Voir l’état des variables ou évaluer des expressions (watch),
• Voir la pile d’exécution,
• Faire du profiling (pour vérifier quelles sont les parties du code qui consomment le plus de ressources). 
• L’outil est en plus intégré dans la plupart des IDE (PhpStorm, VSCode, etc.) qui simplifient son utilisation et fournissent une interface graphique.

PHPStan sur du Legacy : Un challenge permanent

En 2024, l’utilisation d’outils d’analyse statique est essentielle dans les projets. 
Lors de cette conférence, Frédéric Bouchery nous a présenter les avantages de tels outils sur la qualité de code et la prévention d’erreurs.

L’outil phare pour PHP est PHPStan, son système de niveau et de fichier baseline permet d’augmenter ses exigences de manière progressive (pratique sur du code legacy). Il est conseillé d’atteindre rapidement le niveau 5 ou 6 (vérification du typage), le niveau 9 est un objectif ambitieux et à réserver aux nouveaux projets.

OpenTelemetry : standardiser l'observabilité dans Drupal

Quelques rappels sur l’observabilité d’une application :

• WHAT : les logs (journaux horodatés d’événements qui se sont déroulés dans le SI),
• WHERE : les traces (vue d’ensemble des composants appelés),
• WHEN : les métriques (mesures capturées au moment de l’exécution). OpenTelemetry (Otel) est un framework d’observabilité open source disposant d’un ensemble d’outils (collector, opérateur K8s, etc.), et qui permet de standardiser le format des données d’observabilité. C’est une solution plutôt orientée Cloud dans sa conception et elle peut s’intégrer dans plusieurs langages de programmation via des APIs/SDKs, dont le PHP (stable) ! PHP dispose également d’une extension pour utiliser Otel (l’extension grpc est aussi recommandée pour ne pas utiliser le protocole http, plus lent). Pendant la conférence, une démo a été faite de son intégration dans Drupal. Deux modules sont en dev ou bêta, ils ne proposent pas d’auto-instrumentation pour le moment et les remontées sont basées uniquement sur les événements/hooks. Une solution plus avancée basée sur un package Symfony est en cours de publication. Il existe également une extension PHP : opentelemetry.

Sécurité dans Drupal : bonnes pratiques et rappels essentiels

Il s’agit là de rappels, parfois évidents, qu’on connaît plus ou moins et qui pourtant sont souvent non mis en place. Les grands principes de la sécurité sont :

• On bloque tout et on n’autorise que ce dont on a besoin (ce qui parfois est contraignant),
• On ne fait confiance à personne (on teste les saisies utilisateurs côté client ET côté serveur).

Pour le reste, le cœur de Drupal implémente déjà quelques règles qui sont implémentées dans le .htaccess à la racine du répertoire public. Mais faut-il encore que ce fichier soit interprété par le serveur web (coucou Nginx). 
Ce fichier est censé protéger l’accès à certains fichiers sensibles de Drupal qui pourraient être exposés via le serveur Web. Les sécurités implémentées comme le « trusted host pattern » ne sont pas là pour qu’on les contourne ! Il faut les utiliser convenablement ! Quelques bonnes pratiques qui ont été abordées pendant la conférence :

• Les informations sensibles ne doivent pas être versionnées (mots de passe etc.),
• Les éléments sensibles devraient être localisés en dehors de la racine du serveur web (fichiers privés, configurations etc.),
• L'utilisation d'HTTPS doit être faite partout : implémenter les en-têtes de sécurité (CORS, HSTS, etc.) et supprimer les en-têtes non utiles et verbeuses comme les en-têtes Drupal,
• Du côté de l'utilisateur : compte nominatif, politique de mot de passe forte, authentification à double facteur, désactiver le compte admin par défaut, n’attribuer que les permissions nécessaires aux rôles.

Avec FrankenPHP, PHP revient d'entre les morts

FrankenPHP, c’est une application serveur qui réunit les avantages d’un serveur web et du moteur d’exécution php-fpm. Elle est compatible avec les applications PHP (8.2 minimum) dont Drupal ! Elle a été développée pour simplifier les déploiements, notamment sur les plateformes cloud car elle ne nécessite qu’un binaire (C + Go + PHP) et ne nécessite pas de dépendances externes. C’est une application qui repose sur le serveur web Caddy, développé pour le Cloud et qui embarque nativement les fonctionnalités suivantes : déploiement de config à chaud, renouvellement de certificats automatique, support des fonctionnalités du web HTTP2/HTTP3, Early Hints (HTTP 103), gestion des communications en temps réel (via Mercure), mode workers, support des logs structurés et interfaçage avec des outils comme Prometheus, etc. Le projet, porté par Les-Tilleuls.coop semble très prometteur au vu des performances face à ses concurrents tels que Swoole et RoadRunner (qui demandent à adapter leur code PHP) et est boosté par la communauté Laravel avec Laravel Octane. Soyons fous ! Et si Drupal faisait moins de choses au runtime ? Plus un constat qu’une véritable conférence, cette présentation très technique permet de dresser la liste de pistes pour améliorer la réactivité et la performance du cœur de Drupal, espérons que cela lance des vocations ?

Tests automatisés sur Drupal : Méthodes et outils essentiels

Voici une présentation des différents types de tests :

• Les tests manuels
• Les Tests semi-auto, validations manuelles des exceptions : backstopJS
• Les Tests auto behat cucumber s'intègrent bien avec phpunit. 

Focus sur Drupal :

• UnitTest : Unitaire seulement, pas de bootstrap, très rapide (0,01s) extends unitTestCase,
• KernelTest : Bootstrap minimal, pas de thème, rapide (0,5/1s) extends kernelTestCase,
• FunctionalTest : Bootstrap complet, lent (> 10s) extend BrowserTestBase,
• WebDriverTestBase. Démo d’exécution de tests PHPUnit :  https://www.drupal.org/node/2116263. composer require --dev -W drupal/core-dev vi phpunit.xml ./vendor/bin/phpunit (modules/datetime/tests/src/Unit/Plugin/migrate/field/DateFieldTest.php) Présentation de son exécution dans la CI de drupal.org (gitlab-ci).

10 Modules Indispensables pour l'administration de vos sites Drupal

1. Block Content Permissions,
2. Block Permissions (permissions d'admin),
3. Menu Admin per Menu,
4. Admin menu swap : menu d'admin spécifique à un rôle,
5. View Unpublished,
6. Taxonomy Access Fix : très riche et pratique,
7. Redirect After Login (par rôles),
8. Simplify : masquer des champs ou infos sur les formulaires d'édition,
9. Allowed Formats : RTE,
10. Rename Admin Paths.

L’an prochain on revient !

Les évènements Drupal sont d’abord une occasion pour rencontrer la communauté dans un environnement convivial, en dehors des journées rythmées par les échéances de nos projets, et des issues sur drupal.org.

Ce sont des moments importants où l’on y aborde les sujets du moment et surtout où l’on confronte nos bonnes pratiques/processus avec l’état de l’art qui évolue, en particulier dans le monde du Web !

La communauté est riche d’enseignements, bienveillante et permet de progresser ! 
On se donne donc probablement rendez-vous lors d’un prochain évènement.