Retour sur les Drupal Dev Days 2017

Du 21 au 25 mars 2017 ont eu lieu les Drupal Developer Days à Séville. Environ 280 personnes y ont participé.

Cela était très sympathique et enrichissant d'être au contact avec la communauté internationale et des nombreux français sur place :).

L'ambiance est bien différente d'une DrupalCon, on est moins noyé dans la masse et il est plus facile d'aborder et discuter avec des personnes « influentes/connues » dans la communauté.

Au niveau du lieu, nous étions dans le fort d'un parc d'attraction à thème pirate. La zone centrale du fort servait à la fois pour les sprints, les repas et les keynotes. Autant le fait d'avoir une seule zone pour les sprints était plutôt pas mal, autant le fait que cela serve également aux keynotes faisait que l'on était obligé d'y assister et c'était un peu difficile de se concentrer sur autre chose.

Voici un résumé des 5 jours avec les conférences auxquelles j'ai assisté.

Mardi

Sprint :

• J'ai refait un patch pour corriger un bug dans le noyau Drupal concernant l'affichage des résumés de résultats de view.
• Entity share :
  • Préparation d'un environnement de test/développement et d'un sous-module fournissant de la configuration par défaut.
  • Correction du transfert de fichier si le dossier de destination n'existait pas : https://www.drupal.org/node/2859504
• Conversion de tests simpletest en kernel tests sur mes modules Context profile role et Image styles mapping.

Challenges of using a single theme for a complex multi-site Drupal 8 installation

Présentation sur comment organiser un thème pour qu'il puisse être utilisé sur plusieurs sites ayant une base commune de présentation. Lorsqu'on a le cas de plusieurs sites qui se ressemble avec le même fonctionnel, en général un multi-site, on va plutôt s'orienter vers un thème commun aux sites puis faire de l'héritage de thème. Par contre dans le cas d'un projet avec de fortes contraintes de planning, il est intéressant d'avoir un seul thème bien pensé.

Il a bien été fait mention de l'importance d'organiser ces fichiers SASS afin d'éviter tout effet de bord et de profiter au maximum des fonctionnalités offertes par SASS (inclusion, mixin, etc.).

Et surtout l'importance de la communication à toutes les étapes du projet entre les développeurs front end et le reste de l'équipe, que ce soit avec le chef de projet, les autres développeurs (site building, back end). De manière à ce que par exemple des besoins de classes CSS, de configuration particulière (champs dans les vues au lieu de view mode), etc. puissent être remontés au plus tôt afin de faciliter le travail de theming.

A Cautionary Tale for Defensive Programmers

Présentation sur comment et pourquoi faire en sorte que les erreurs dans le code remonte au plus tôt (en développement en tout cas) et/ou faciliter leur débogage en fournissant les informations nécessaires. Par exemple, si l'on peut suggérer des pistes de résolution.

Pour cela l'utilisation du typage des paramètres en entrée et sortie de méthode, mais aussi le fait de lever des exceptions est fort utile. Attention à ne catcher les exceptions que si l'on souhaite effectuer une opération avant de la faire remonter ou que l'on souhaite la gérer.

Drupal 8.3.0: The features are ready. Are you?

Présentation des nouveautés apportées par la version 8.3.0 dont beaucoup d'améliorations de l'interface. Rappel du cycle de développement de Drupal 8 avec l'adoption du versionnement sémantique et la sortie d'une version mineure tous les 6 mois.

Rappel également du principe des modules expérimentaux et des bilans de l'état de ces derniers. Hormis Migrate, il ne faut pas s'en servir pour les projets. Personnellement, j'utilise également le module inline form errors car il ne stocke rien en base de données, pas de table et pas de configuration.

Mercredi

Les organisateurs nous ont fait la surprise d'un duo chanteuse/guitariste interprétant des musiques forts sympathiques le temps du repas.

Sprint :

• Discussion avec bojanz au sujet du port D8 du module commerce licence afin de lui demander de mettre l'architecture attendue dans l'issue correspondante pour pouvoir aider au port du module (besoin pour le site drupal.fr) et de l'intégration des utilisateurs dans Inline entity form, à ce sujet, il vaut mieux faire un formulaire custom, il y a trop de points gérés de manière non générique dans le noyau pour les formulaires des utilisateurs.
• Discussion avec Wim Leers à propos du module Entity share et sur une manière de résolution de https://www.drupal.org/node/2860886 pour l'ajout de données stockées dans les valeurs de champs comme par exemple les attributs title et alt des champs images.
• Mise à jour de l'issue https://www.drupal.org/node/2713495 : à propos d'un problème d'affichage dans le BO de Features.
• Création d'un patch pour la conversion de test simpletest en test fonctionnel PhpUnit dans le module Features UI.

All your data are belong to geo

Première keynote de ces Drupal Dev Days. Elle portait sur l'importance de la géolocalisation des données afin de permettre de la visualisation et de mieux les comprendre. Il y avait également un tour d'horizon des modules de géolocalisation et des services externes fournissant des cartes.

Advanced Configuration Management with Config Split et al.

Présentation des différentes utilisations possibles du module config split. Présentation de différents workflows de gestion de la configuration.

Je reste néanmoins pour l'utilisation de Features car je préfère avoir la configuration qui va avec un module dans le module et pas noyée parmi les autres fichiers de configuration.

Point intéressant, il y a un événement déclenché lorsque une entité de configuration requiert une entité de contenu et qu'elle n'est pas présente.

Jeudi

Sprint :

• Ajout de captures écran pour l'issue de Views sur l'affichage des résumés de résultats.
• Création d'un patch pour les données de champs entity reference particuliers dans JSON API.

Drupal, platforms and the future of e-commerce

Présentation sur l'importance d'engager ses clients et de les voir vraiment comme une communauté afin de pouvoir vendre sur des marchés de niches car les autres marchés sont déjà pris et imbattables.

Créer la communauté d'abord, quitte à la créer là où ils sont déjà, Facebook par exemple. Puis essayer de vendre. Utiliser le fait que les gens ont envie d'être fiers d'achats particuliers, par exemple acheter le dernier smartphone sorti par rapport à acheter un câble.

Pas nécessairement besoin d'avoir un site internet, utiliser les réseaux sociaux à son avantage et déléguer, la distribution à des services dédiés (Amazon par exemple).

Introducing the UI Patterns module: use atomic UI components everywhere in Drupal 8

Le module permet de déclarer des composants réutilisables et d'avoir un guide de style générés automatiquement.

Pour l'instant il faut déclarer ses patterns dans des fichiers YAML, mais une intégration future avec des systèmes comme Pattern lab et Fractal (qui sont des outils utilisés pour gérer des composants) est prévue.

Dans son composant, il faut déclarer des champs, qui peuvent être d'autres composants et des données de démonstration (facultatif).

Le module met à disposition une fonction de thème par composant, utilisable donc dans les renderable array, mais aussi dans les templates twig. Et une fonction de thème équivalente mais qui utilisera les données de démo renseignées dans le fichier yaml. Il est également possible d'associer chaque composant à des librairies et même des librairies déclarées dans le fichier YAML du composant directement afin quelles soient chargées si nécessaire.

Des sous-modules permettent une intégration, dans les champs, les layouts, les vues, display suite, field group afin d'utiliser ces composants à ces différents endroits en permettant un mapping entre les champs déclarés dans le pattern et les champs placés dans un field group par exemple.

Des suggestions, plutôt à destination des fonctions de preprocess, sont mises en place et sont différenciées en fonction de leur utilisation, vue, field_group , etc. Afin de pouvoir avoir des preprocess ciblés.

Module très prometteur, qui demande sur un projet, un bon cadrage initial et un très bon découpage des composants, mais qui permet sur le long terme une bonne maintenabilité.

Commerce 2.x: Lessons learned

Les personnes développant Drupal commerce sont parties du constat/supposition suivant :

• ils ont besoins de nombreuses librairies externes (dont leurs propres librairies génériques) installables via composer
• Drupal 8 lui-même requiert de nombreuses librairies, ce qui va rendre de plus en plus obligatoire l'utilisation de composer
• Drupal 8 s'adresse à des sites plus complexes, les « petits » sites étant désormais faits en Wordpress ou Wix (même si Drupal 8 peut s'adresser à des petits sites, il est vrai qu'il faut s'y connaître si on veut faire plus que du site building).

D'où l'idée que les personnes utilisant Drupal 8 ont un profil de plus en plus technique, avec également l'obligation d'utiliser des outils comme composer.

Du coup, il a été supposé que même les site builder se mettraient a minima à Twig.

Drupal Commerce est donc plutôt à destination des développeurs.

Beaucoup d'éléments de configuration ont été retirés en faveur de templates twig surchargeables et preprocessables ou de configuration déclarable via des fichiers YAML directement dans des modules. Cela afin d'éviter d'avoir à maintenir des interfaces de configuration peu utilisées et qui ne conviendrait pas pour les besoins métiers que requièrent les sites e-commerce.

Drupal Commerce s'adresse désormais à des problématiques plus complexes plus facilement. Même si Commerce est pensé pour répondre au cas simple dès l'installation. On verra bien sur le long terme si même les petits sites pourront profiter des avancées de Drupal Commerce.

Do your best to make your web page accessible

Sensibilisation à l'accessibilité, rappel de son importance et que c'est aussi bon pour le SEO. Conseils, liste de modules. Et surtout ce n'est pas à prendre en compte à la fin du projet.

Vendredi

Sprint :

• Parcours d'issues
• Traductions : plus de chaînes françaises sans suggestion pour la version 8.3.0-rc2
• Mentoring de traduction : afin d'apprendre à beram à contribuer des traductions.

Drupal 8 Caching overview

Présentation sur les différents types de cache dans Drupal, rappel d'utilisation basique.

Information sur la nécessité d'utiliser un backend de cache autre que la base de données car Drupal 8 ayant un système de cache permettant de stocker indéfiniment le rendu des pages, et Drupal 8 faisant du cache par URL pour les anonymes, il est facile de faire grossir la taille du cache.

De plus rappel du Lazy builder qui est un mécanisme du cache permettant de mettre en cache des parties de page tout en ayant à l'intérieur une partie variable non cachée comme un lien flag.

Il a également été fait mention du module Views Custom Cache Tags (que j'avais pas encore testé) permettant de définir ces propres tags de cache à utiliser dans les vues à invalider soi-même dans du code custom. Le but étant de palier à un vidage de cache systématique des vues à la moindre modification des entités. Par exemple, l'ajout, suppression ou modification d'un contenu entraîne par défaut un vidage du cache de toutes les vues basées sur des contenus. Alors que souvent les vues sont filtrées sur un type de contenu particulier ou une combinaison de filtre particulière. En faisant une invalidation custom selon les besoins cela évite d'avoir le cache des vues de vider systématiquement.

Wait, there’s more! - Advanced debugging tactics

Concentré d'astuces et outils pour le débug, très intéressant. Toujours intéressant d'apprendre des astuces sur les outils que l'on utilise.

Notamment le système de macro de PhpStorm, permettant d'enregistrer des suites de commandes pour les rejouer.

Devel - D8 release party

Présentation intéressante sur l'évolution de Devel dans Drupal 8.

Par rapport au module Twig Xdebug, il existe une fonction twig devel_breakpoint faisant déjà la même chose.

Attention à vider les données collectées par le webprofiler, car à chaque requête le nombre de données collectées peut monter à 2Mo.

Une intégration avec XHProf en cours.

Improving content creation with Paragraphs

Présentation du module Paragraphs, mais surtout le point intéressant était le module Paragraphs Collection encore très expérimental mais avec de très bonnes idées, par exemple :

• une bibliothèque de paragraphes : les paragraphes sont par leur conception liés à leur entité parente et non réutilisables sur une autre entité. L'idée de la bibliothèque de paragraphes est de permettre leur réutilisation en choisissant des paragraphes existants à cloner.
• les propriétés ou behaviors de paragraphes : avec un exemple, on a souvent le cas d'un type de paragraphe « titre, texte et image » et il faut donner la possibilité d'avoir l'image soit à gauche, soit à droite, pour ce faire on ajoute en général un champ permettant ce choix et le reste est fait dans des preprocess ou des templates twig. L'idée des propriétés de paragraphes est de stocker l'information image à gauche ou droite de manière sérializée dans le paragraphe et plus dans un champ. Ce qui par exemple pour des paragraphes slideshow avec beaucoup d'options rendre paramétrables pour faire des variations, évite de créer de nombreux champs.

Samedi

Sprint :

• Discussion avec Webchick et xjm à propos des module expérimentaux. En effet, le nouveau système des modules expérimentaux, qu'il ne faut pas utiliser en production (sauf exceptions comme Migrate), me rendait perplexe par rapport à la stabilité des modules communautaires. Notamment avec le cas de Drupal 8.3.x et le module de layout sur lequel vont s'appuyer Display Suite, Panels, Page Manager. Par exemple DS a une version stable depuis la sortie de Drupal 8, et là désormais il y a une autre version qui s'appuie sur un module expérimental du noyau, comment gérer la mise à jour… Mais inquiétudes concernaient également la vitesse d'avancement de ces modules et de l'état de leurs mainteneurs car désormais ils doivent théoriquement maintenir une version ne s'appuyant pas sur les modules expérimentaux et une version s'y appuyant…
  J'ai été rassuré que désormais afin de permettre aux modules expérimentaux d'atteindre plus vite le statut de module stable, ils étaient introduits plutôt en version bêta qu'en alpha comme cela a pu être le cas des précédents modules expérimentaux (et qui le sont toujours !) comme Workflow et Content moderation.
  Dans le cas de DS et Panels, ils s'appuyaient déjà sur un module Layout Plugin commun, donc cela fait que le travail d'adaptation au noyau a été réduit. Et il y a une discussion avec les mainteneurs de ces modules avant d'introduire un ou des modules expérimentaux dans le noyau.
  Un point de vue que je n'avais pas perçu avant sur les modules expérimentaux est qu'ils permettent d'introduire « rapidement » du code dans le noyau, et de permettre aux contributeurs de tester/développer plus rapidement et facilement que si ce code restait sous forme de patchs noyés dans des issues. Donc bel et bien à ne pas utiliser sur des projets.
  Note : Cette discussion a eu lieu l'après-midi, la keynote de Webchick ayant eu lieu le matin.
• Discussion avec Berdir sur le cache et le cache Redis notamment concernant une issue de caches non vidés https://www.drupal.org/node/2765895 dont le problème a été résolu.
• Discussion avec beram sur la gestion des traductions dans Entity share.

Debunking Myths to Drupal 8 Adoption

Keynote de Webchick, avec un rappel du système des modules expérimentaux, présentation de la démarche de facilitation de l'adoption car de nombreux clients attendent encore que certains modules soient stables ou portés, mais du coup par manque de projets Drupal 8, les mainteneurs de ces modules n'ont pas le temps de stabiliser/porter les modules. Le dilemme de l’œuf et la poule.

Getting up to speed with testing on Drupal 8

Atelier sur les tests automatisés avec Drupal 8, s'agissant d'un atelier d'une durée prévue de 4h, mis sur un créneau de 2h (et qui a finalement duré 3h :)), il a « juste » était fait une présentation d'un skeleton de projet Drupal 8 avec tout ce qu'il faut pour les tests https://github.com/pfrenssen/drupal-project.

Très intéressant de voir le scripting via Phing, à voir si je ne vais pas remplacer certains scripts custom par Phing ou par du Ansible qui semble plus complexe mais également plus puissant.

Passage en revue de tous les types de tests : Phpunit (unit, kernel, functional), Behat, Javascript, émulateur de navigateur, etc.

Drupalize remote data with external entities

Présentation du module Remote entity API, qui permet d'afficher des données distantes dans Drupal et de manipuler ces données comme des entités de contenu. Ce qui permet par exemple d'utiliser les modes d'affichage.

Le module ne stocke aucune donnée sur le site, mis à part peut-être du cache, pour avoir rapidement tester, les tables des champs ajoutés sur ce type d'entité ne sont pas créées.

Les points négatifs sont par exemples sont intégrations avec Search API, comment faire pour invalider des données indexées par Search API puisque les données sont modifiées en dehors du site. De même comment faire du cache pouvant être invalidé. Il manque une intégration avec Views. La gestion de champs à valeurs multiples et actuellement le parsing de données externe ne peut se faire que sur des structures assez simples comme on peut trouver sur http://jsonplaceholder.typicode.com.

Le module est prometteur, je le résumerai en un Aggregator (module du noyau) avancé.

Conclusion

Événement très enrichissant que ce soit au niveau connaissances que contact avec les personnes de la communauté.

Merci aux organisateurs pour ce super événement.

Merci aux participants et aux personnes m'ayant mentorés.

Et merci à Smile de m'y avoir envoyé.