Retours sur les Drupal Dev Days 2019

Il y a 3 semaines, du 10 au 14 juin, avaient lieu les Drupal Dev Days 2019 qui se tenaient cette année à Cluj-Napoca en Roumanie.

Cette édition a accueilli environ 240 participants.

Voici mes retours sur cet événement.

Sprints

Entity share

Initialisation de tests automatisés pour le sous-module Entity share client (https://www.drupal.org/project/entity_share/issues/2909022) et refactorisation pour la création des autres tests.

Coder

Ajout d’une règle afin que le nom machine d’un bloc soit préfixé par le nom machine du thème dans lequel ce bloc est positionné : https://www.drupal.org/project/coder/issues/3061184

Jour 1

Journée consacrée aux sprints.

En discutant avec les personnes de la même table, j’ai pu avoir un retour de https://www.drupal.org/u/eiriksm sur le fait qu’il utilisait Entity share sur un projet E-commerce.

Jour 2

Keynote: The fourth wave of the content management system

C’était une présentation de l’article https://preston.so/writing/the-distributed-cms-how-the-decoupled-cms-endgame-will-impact-your-organization avec des informations supplémentaires. Et qui faisait surtout la promotion de GatsbyJS.

Tour d'horizon des utilisations des contenus sur les sites et comment cela a évolué depuis légèrement avant les années 2000.

Coût de l'infrastructure pouvant être important sur des sites Drupal « classiques » à fort trafic : site Drupal à 1 million de dollars par an pour l’hébergement.

Possibilité de services interchangeables, les CMS évoluent trop vite.

Aspect sécurité : les architectures découplées permettent de verrouiller les parties CMS et d’empêcher l’accès externe à certains services.

« A CMS renaissance is coming »

Au niveau de la communauté Drupal, il n’est plus possible de « servir » des développeurs PHP. Javascript est un passage obligé.

Désormais un CMS est plus qu'un outil (exemples avec de vieilles interfaces pour des solutions métiers), il faut gérer l'expérience utilisateur. Exemple de Calypso en Wordpress.

D’où l’existence de l’Admin UI initiative pour moderniser l’interface de Drupal 8.

Point sur les concurrents Headless à Drupal :

• Contentful

• Prismic

• Sanity.io

Avec un Drupal Découplé, il y a la possibilité de découplé les mises à jour entre Drupal et le framework front.

Full presentational decoupling : parties de pages qui viennent de différents services externes. La recherche, les formulaires, les contenus, etc.

On parle désormais de Distributed CMS / Content Mesh.

Diminution des coûts car chaque composants peut être utilisé au minimum de ce qui est requis.

Aspect sécurité : plus compliqué d’être attaqué si plein de services différents et cloisonnés sont utilisés.

Possibilité de travailler sur un site Drupal hors-ligne.

Deep dive into the dependency injection container in Drupal 8

Version anglaise de la présentation donnée au Drupalcamp Paris 2019 (je n’avais pas assisté à cette session lors du camp) : https://paris2019.drupal.fr/programme/sessions/le-container-dinjections-de-dependances-aux-petits-oignons

Conférence très technique, le conférencier maîtrise son sujet, mais je ne vois pas l’utilité au quotidien avec Drupal 8.

Les parties fichier services.yml et ServiceProvider pour altérer des services dynamiquement me parlaient très bien, mais pas le reste de la présentation.

Quelques points que j’ai noté :

• $container->get is bad.

• Dans Drupal les services sont publics pour pouvoir charger des services dans les parties procédurales.

• Autowiring is coming.

Progressively Decoupled Drupal: Lessons Learnt

Dû à la pause du midi courte vu qu’il n’y avait pas de repas prévu le midi, j’ai loupé le début de la présentation qui devait parler des avantages… Donc voici principalement les désavantages et problèmes rencontrés :

• pas de notion de behaviour pour le Javascript,

• pas de twig debug disponible,

• lazy loading : le module Blazy ne marche pas, obligé de faire manuellement selon le framework choisi,

• beaucoup de code custom nécessaire :

  • préparation des données pour le front,

  • gestion des métadonnées de cache,

• attention à la maintenance, difficulté d’intégration de personne sur le projet.

Il faut considérer les fonctionnalités et le design pour évaluer si le découplé est utile.

Content driven eCommerce with Drupal Commerce

Présentation sur l’utilité de l’aspect CMS dans le E-commerce.

Fournir de l'information suffisante pour que le visiteur achète, plus besoin de magasin physique ou de catalogue.

Avec un CMS, on peut aller au-delà de simplement faire des sites catalogues :

• personnalisation du contenu, des images affichées, par rapport par exemple à la couleur préférée de l'utilisateur,

• articles sur les produits pour inspirer à leur utilisation.

State of Drupal 9

Si on suit l’actualité Drupal 8, entre les articles des blogs de la communauté et les contenus des Driesnote, cette session est un rappel de tout cela.

Rappel de l’adoption du semantic versionning pour le noyau et des scheduled releases avec une nouvelle version mineure tous les 6 mois qui permet de mettre à jour les librairies externes.

Rappel de la mise en place du système de dépréciation permettant de retirer du code à chaque version majeure.

Rappel des dates de sorties pour le passage à Drupal 9 : Juin 2020

Rappel des outils pour faciliter le passage à Drupal 9 :

• Phpstan pour une analyse statique du code déprécié,

• Drupal CI pour tester le code sur drupal.org,

• indications sur la page des modules de ce qu’il faut faire pour que le module soit prêt pour Drupal 9

Au niveau de gestion du code dépréciée :

• code custom sur les projets : retirer le code déprécié maintenant,

• module contribué : rester à jour par rapport aux versions supportées du noyau. Attention : ce que cela sous-entend, il ne faut pas prendre la dernière version du noyau car l’avant-dernière version étant également supportée, il ne faut pas retirer de code déprécié entre l’avant-dernière et la dernière version car les sites sur l’avant-dernière version du noyau cesseraient de fonctionner.

Question posée par l’auditoire : Devront-nous créer une branche 9.x dans les modules contribués, or est-ce que Drupal 9 acceptera des versions de branches 8.x-y.x de manière transparente ?

Pour permettre cela il faudrait que les modules contribués passent également au semantic versioning pour retirer la partie 8.x des versions des modules contribués. Le but sur le long terme est d’avoir des modules compatibles avec différentes versions majeures de Drupal.

Creating an enterprise level editorial experience for Drupal 8 using React

État des lieux des interfaces pour l’édition des contenus.

Désormais le contenu doit être distribué sur différents canaux, avoir seulement un site n’est plus suffisant.

Il y a également une discussion si Twig est encore d’actualité.

3 notions :

• Content management

• Content delivery

• Content presentation

Aucun cas n’est identique : écoutez vos éditeurs

Commencé petit pour l’amélioration progressive de l’interface.

En ce moment dans Drupal, il y a :

• les paragraphes

• la bibliothèque de média

• layout builder

Avec un niveau d’attente très élevé sur l’accessibilité pour ce qui concerne le noyau.

En dehors de Drupal :

• Elementor dans Wordpress : un constructeur de page en direct

• Content planner

• Guthenberg : pas bien pour l'accessibilité. Et le contenu n’est pas structuré

• DX8 : un Drupal customisé basé sur des paragraphes (apparemment pas accessible publiquement)

• Openstory.io

• (Gizmo? Plus certain de ce point)

• Glazed builder

• Droopler

Les points difficiles lors de la contribution :

• le rafraîchissement de pages,

• le temps passé à construire (exemple d’imbrication de paragraphes) au lieu de créer du contenu.

Démonstration d’une interface en React, faites pour un client et anonymisée, pour contribuer des paragraphes.

Point indiquant que pour ce genre d’utilisation, GraphQL est plus adapté que la JSON:API.

Jour 3

Keynote: Security, Drupal 9, and the Changing Web Landscape

Les dépendances rythment les nouvelles versions de Drupal et cette présentation donne un aperçu de la complexité du sujet.

1/3 des mises à jour de sécurité de Drupal 8 sont pour des mises à jour de sécurité des dépendances.

1/2 des mises à jour de Drupal 8 sont pour des mises à jour des dépendances.

Coordonner les sorties de version entre composants est difficile et cela est également complexifié par les nouvelles versions de PHP.

Il y a les dépendances PHP, mais aussi les dépendances Javascript, exemple avec jQuery 3 qui n’a pas était bon sur la gestion des failles de sécurité. Et qui a dû être mis à jour en urgence dans le noyau en entraînant des problèmes de rétro-compatibilité.

Lorsqu’il a été question de l’utilisation de React pour la refonte du Back office de Drupal 8, la gestion des versions et la politique de sécurité de React ont été étudié, cela a mis des doutes sur l’utilisation du Framework dans Drupal 8.

Pour sur NodeJS, NPM et les micro paquets.

Exemple d’un paquet « leftpad » (qui d’ailleurs ne s’occuper que de la partie gauche des chaînes, pas la partie droite…), dépublié par son mainteneur et qui a détruit des milliers de build de projets reposant dessus. Cela a été le seul cas où Github (ou NPM, je ne sais plus) a republié un dépôt sans demander l’accord préalable du propriétaire du dépôt.

https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos

Autre exemple de dépendance en cascade : drupal-admin-ui, la librairie Javascript pour la refonte du Back office de Drupal possède 1732 dépendances.

C’est compliqué de limiter les dépendances, même si c’est mieux pour réduire la surface de potentielle faille.

Au niveau organisation pour l’équipe de sécurité Drupal, cela implique de vérifier les dépendances de dépendances, etc.

Quelques commandes utiles :

• composer install –no-scripts : l’option no-script permet de ne pas déclencher de script embarqué dans le code téléchargé et ainsi limiter le déclenchement de code malvaillant

• yarn audit / npm audit : pour vérifier les mises à jour de sécurité des paquets Javascript.

Au niveau des applications, c’est désormais la nouvelle norme cette gestion des dépendances.

The past, present, and future of Drupal Commerce

Présentation promotionnelle sur Drupal Commerce. Cela a été une version courte de la présentation faîtes à chaque événement.

• 40 premiers modules communautaires autour de Drupal Commerce 1.x sont désormais dans Commerce 2.x.

• Sortie d’une version tous les mois.

• Écosystème en bonne santé d’agences partenaires qui utilisent la solution et y contribuent soit en développant directement de nouvelles fonctionnalités, soit en finançant Centarro (ex-Commerce Guys)

• Utilisation des API du noyau pour améliorer l’expérience utilisateur

• Développement des outils Centarro en open source et qui bénéficient à toutes la communauté Drupal.

Remarque de l’auditoire : il serait bien que Drupal Commerce ait des étapes d'aide à la configuration après installation pour faciliter la configuration notamment lorsqu’on débute avec la solution.

Frontend Security is a Thing

Passage en revue de problème de sécurité côté navigateur :

• injection SQL

• XSS

• Javascript injecté sur les pages du sites :

  • Reflected

  • Persistent

• CSRF : utilisation des accès d’autrui

• attribut : target = _blank permet les redirections vers des sites malicieux

Recommandations :

• utiliser l’attribut sandbox de la balise iframe,

• ne jamais avoir confiance dans les données navigateur.

Tous les sites ont des failles, la question est quand est-ce qu’elles vont être exploitées.

La présentation était intéressante, mais il y avait selon moi des points d’améliorations à faire sur la présentation :

• plus de slides pour illustrer les exemples, car il y avait trop de temps passer par slide pour donner des exemples sans trace écrite ou illustration, cela aurait aussi un peu plus dynamiser la présentation,

• plus de dynamisme dans la présentation, certes il y a la difficulté de passer en fin de journée, mais la présentation était très monotone.

Jour 4

Keynote: The greatest asset Drupal holds for growth is you…

Conférence sur comment communiquer sur Drupal et ainsi faire grandir la communauté.

L’initiative sur le marketing autour de Drupal a produit des outils afin de communiquer sur Drupal.

https://www.drupal.org/community/agency-marketing

Il y a notamment le Drupal brand book pour parler de Drupal, cela précise les mots à utiliser, les polices, taille de polices, couleurs, etc.

Une initiative de traduction du brand book et des vidéos de promotion de Drupal est en cours.

Cela permet de contribuer à la marque, d’avoir une image de marque uniformisée. Pour contribuer à l’image de marque, toujours présenter le meilleur de nous-même.

Il y a des présentations d’interview de membres de la communauté.

Comment faire grandir la communauté ou aider sur la communication :

• en ajoutant de superbes photos dans une banque d’image réutilisable par la communauté, merci de mentionner les auteurs des photos a minima,

• en présentant le projet à de nouvelles personnes,

• en aidant les autres membres à progresser,

• en célébrant les succès de la communauté,

• en traduisant les supports marketing,

• en s’investissant dans une association Drupal locale,

• ...

Passage sur le bureau de l’association Drupal :

• l’association supporte la diversité et l’inclusion dans le projet,

• changement de logo pour le pride month, mais cela n’est pas suffisant,

• inclusion dans le bureau de groupe sous-représenté.

Pour avoir une section dans /community et faire avancer la communauté, il suffit de demander à Rachel Lawson.

Actuellement 2 membres du bureau sont élus par la communauté, mais cela peut monter à 4.

En conclusion, vous représentez tous Drupal !

Comme il s’agissait de la dernière keynote de l’événement, il y avait présentation des chiffres sur l’événement (dont les 240 participants), et l’annonce que les prochains Drupal Dev Days auront lieu en Belgique !

Dynamic migrations using templates

Version session de l’article https://www.webomelette.com/dynamic-migrations-using-templates-drupal-8

Rappel historique sur les migrations en Drupal 8.

Ce sont des plugins basés sur des fichiers YAML.

Il y a un système de plugin dérivé et du coup la possibilité d'altérer la configuration des templates en YAML dynamiquement en fonction de la langue (cas d’usage typique).

Dépôt git des exemples de code : https://github.com/upchuk/advanced_migrations

Drupal Admin UI Modernization Initiative

État des lieux / présentation de l’initiative.

L’initiative consiste en :

• Interface d’administration découplée -> Changements Javascript dans le noyau

• Recherche sur les utilisateurs -> Changements d’expérience utilisateur dans le noyau

• Système de design de Drupal -> Changements d’interface dans le noyau

Les moyens utilisés par l’initiative pour faire des choix :

• sondage,

• tri de cartes : à partir de cartes représentant des pages ou du contenu, essayer de regrouper les cartes qui doivent aller ensemble,

• études comparatives,

• tests de wireframes.

Des solutions proposées :

• enregistrement automatique des révisions en attente lors de l’édition,

• ajout d’un nouveau rôle éditeur,

• système de design de Drupal : travail sur des composants,

• nouveau thème d’administration : Claro.

En chantier / sur du long terme :

• re-design complet de l’agencement et de la navigation,

• intégration des changements UX,

• gestion du contraste élevé,

• interface d’administration découplée.

CMI 2.0 and you

Même présentation que celle donnée lors de Drupal Europe en 2018, avec de légères modifications.

Les objectifs de l’initiative CMI 2.0 :

• documentation :

  • pour les utilisateurs sur les projets, les bonnes pratiques, définir des standards d’utilisation,

  • pour les développeurs pour utiliser l’API disponible,

• permettre des configuration spécifique par environnement : cible D8.8

• permettre des workflows de configuration inter-site : cible D9

Depuis Drupal 8.6, possible d’installer un site depuis une configuration existante : drush site:install --existing-config

Mais ne fonctionne pas pour les profils implémentants un hook_install.

Autres notions qui vont être introduites afin d’améliorer l’API :

• Config export storage

• Config storage transform events / subscribers

• Config environment module (experimental) : un environnement actif à la fois par rapport à config split qui permet des combinaisons de splits.

• Config directory in settings

Le problème est que la totalité des cas d’usages n’a pas nécessairement été évaluée.

En attendant, utilisez Config split, idéalement avec un split actif par environnement.

Drupal Debug: improve your developer experience

Version anglaise de la présentation donnée au Drupalcamp Paris 2019 : https://paris2019.drupal.fr/programme/sessions/lexperience-developpeur-dans-drupal-ameliorez-la

Par rapport à la présentation du Drupalcamp Paris, j’ai retenu en plus que le Webprofiler (sous module de Devel) a 2 versions de retard sur celui de Symfony et n’est pas une intégration dans Drupal du Webprofiler de Symfony, mais un calque de ce dernier.

Depuis ces Drupal Dev Days, j’ai modifié ma stack de projet Drupal pour utiliser Drupal Debug, même s’il serait préférable que certaines fonctionnalités soient paramétrables.

J’ai également regroupé les settings.php en un seul endroit afin que des débutants soient moins déroutés et du coup la partie settings de développement est grandement allégée avec Drupal Debug.

Les avantages de Drupal Debug qui m’ont convaincu :

• allégement du settings.php pour le développement,

• pas d’oubli de settings lors du passage en mode développement,

• les erreurs PHP sous forme d’exceptions,

• invalidation automatique du cache pour les routing, services, .module.

Jour 5

[Machine Learning] Creating more relevant search results with "Learn to Rank"

Lorsque le machine learning est utilisé, c’est en général sur des problématiques de prédiction de résultat, dans cette présentation, nous allons nous intéressés aux problématiques de classement de résultat.

La solution, par exemple embarquée dans le module Search API, de booster des mots en provenance de certains champ n’est plus assez pertinente.

Une idée de customisation plus pertinente est de mettre systématiquement dans les requêtes faîtes à Solr un critère sur la fraîcheur (freshness) du contenu.

Faire attention avec le module Layout Builder car on sort du contenu structuré et cela peut avoir un impact sur l’indexation et donc les résultats attendus.

Faire également attention aux métatags qui sont exposés à l’indexation Google, mais pas à Search API.

Ne pas chercher à mettre la logique en PHP, laisser Solr faire le travail.

Au niveau du paramétrage dans Search API :

• pour le serveur Solr :

  • cocher : retrieve result data from solr

  • cocher : highlight excerpt

• pour les processeurs :

  • utiliser : Use highlighted field data, create excerpt

Démonstration d’un outil de ranking. Ranker performance, outil qui compare les résultats de recherche selon un apprentissage, l’apprentissage précédent, le modèle de données d’origine.

L’apprentissage se fait manuellement. Pour une recherche donnée, il est possible de dire si un résultat est bien classé ou non / important ou non. Cet apprentissage est ensuite stocké en fonction de la recherche effectuée et par donnée source. Si l’on vide l’index et que l’on ré-index, l’apprentissage n’est pas perdu.

Afin d’intégrer cette fonctionnalité dans Drupal, le module Search API Learn To Rank https://www.drupal.org/project/search_api_ltr expose un champ de vue permettant d’indiquer dans une recherche si le résulata est pertinent ou non.

Note diverse : Parse mode : edismax

Site de démonstration : http://drupalsear.ch

Layout Builder is here!

Présentation du module Layout Builder.

Alternatives :

• Panel

• Paragraphs

• Display Suite

Les blocs de contenu ont un nouveau sens avec Layout builder.

Possibilité d’avoir des agencements par défauts par type de contenu.

Pour avoir des paramètres d’agencement personnalisés, il faut passer par des classes PHP.

Il vaut mieux mettre les agencements personnalisés dans un module pour ne pas être limité.

Utilisation du module Layout Builder Restrictions afin de limiter les éléments positionnables dans Layout Builder et ainsi éviter les effets de bords et de surcharger l’interface.

Il y a eu une démonstration de customisations sur des agencements, mais le module cité n’avait pas de dépôt Git sur drupal.org.

Sharing configuration in multi-site and multi-profile platforms: A Modern Oddysey

État des lieux de la gestion de la configuration :

• avec Drupal 8.6, possibilité d’installer un site depuis une configuration existante,

• pas d’héritage et de hiérarchie dans les profils d’installation,

• des modules contrib : config filter, config split, config override system, etc.

• possibilité de créer des « task alter » pour altérer la configuration existante avec des options Drush

Pour l’héritage de profil d’installation, il est possible d’obtenir la fonctionnalité en appliquant 2 patchs au noyau. Cela permet de faire de l’héritage, mais aussi de l’exclusion pour ne pas avoir un module d’activé dans un profil enfant si non nécessaire.

Dans l’installation multi-site présentée, le problème est que le dossier d’export de configuration étaient partagés entre les différents profils et que l’information du profil d’installation d’un site est située dans la configuration core.extension

La solution a été d’altérer l’import et l’export de la configuration pour retirer ou injecter cette configuration à la volée lorsque nécessaire par site.

Durant l’installation d’un nouveau site, cela posait des problèmes de validation, d’où un patch pour permettre l’injection.

Durant la vie d’un site, possibilité d’activer de la configuration selon certaines conditions avec le module Config split :

• dans le fichier settings.php activer ou non les splits,

• dans le fichier settings.php, activer ou non des splits selon le nom de domaine requêté,

• activer des splits via des services de surcharges de configuration.

Cela montrait une architecture qui fonctionnait sur ce projet, mais très complexe, et nécessitant beaucoup d’attention sur le découpage des fonctionnalités entre les différents profils pour garantir le fonctionnement des sites.

De plus cela nécessitait de nombreux patchs sur le noyau principalement, dont certains ne finiront certainement pas dans le noyau.

web push notifications campaigns management in Drupal

Les service workers permettent de réagir à des événements émis par le serveur.

Les cas d’usage sont :

• téléchargement de fichiers progressifs,

• répartition de charge côté client,

• expérience hors ligne optimisée,

• cache avancé,

• tâches effectuées en arrière plan.

La push API permet d’avoir une expérience d’application native, émettre des push même lorsque l’on ne navigue pas.

La notification API, elle permet de communiquer avec l’OS en arrière plan. Elle nécessite cependant la permission de l’utilisateur.

Présentation de librairies permettant d’utiliser ces API plus facilement. Besoin de clé privée vapid stockée dans Drupal, en général dans le fichier settings.php.

Conclusion

Les conférences préférées :

1. [Machine Learning] Creating more relevant search results with "Learn to Rank",

2. Dynamic migrations using templates,

3. Keynote : Security, Drupal 9, and the Changing Web Landscape,

4. Keynote : The greatest asset Drupal holds to growth is you…,

5. Sharing configuration in multi-site and multi-profile platforms: A Modern Oddysey.

J’avais déjà annoncé dans un précédent retour sur un événement, il faut que je diminue la quantité de session auxquelles j’assiste car la plupart des sessions, du fait de suivre l’actualité de la communauté, je connaissais déjà le contenu. C’était encore le cas sur ces Drupal Dev Days.

Le « faible » nombre de participants (240) par rapport à l’édition précédente (400) était un peu dommage. Mais inversement, cela permettait d’aborder plus facilement certaines personnes de la communauté incessamment sollicitées.

Autre conséquence, lors des soirées communautaires, il était plus facile de se mêler aux groupes de participants, j’ai ainsi pu nouer contact, principalement avec des participants roumains, belges, tchèques, etc. et consolider des liens, événement après événement, en revoyant les mêmes participants.

À chaque discussion, je parle, entre autres sujets, de l’association Drupal France et du module Entity Share vu que j’y contribue durant l’événement et je tombe régulièrement sur des personnes intéressées et je leur fais une démonstration ce qui est très agréable de faire un module utile pour Smile et pour la communauté. L’appel à session étant fermé pour la prochaine DrupalCon, je pense y faire une BoF pour présenter Entity Share qui n’est pas encore très connu.

Un point également sur les soirées communautaires. De très bonne qualité, excellentes à chaque fois pour rencontrer de nouvelles personnes :

• le mardi soir, un bar dans un lieu avec un certain charme,

• le mercredi soir, soirée jeux de société : à avoir à tous les événements !

• le jeudi soir :

  • visite du quartier historique de la ville, tout proche du lieu de l’événement, par des guides professionnels : à avoir à tous les événements !

  • repas traditionnel Roumain

• le vendredi soir : soirée organisée spontanément par la communauté.

Un très bon événement, merci aux organisateurs, merci à la communauté pour les participants et les présentations, merci aux sponsors et merci à Smile de m’y avoir envoyé.

Photos : https://t.co/PAKnNj2VjU

Vidéos : https://t.co/CeY7eilt2r