Articles de l'utilisateur

Sommaire

- Google Analytics dans le viseur européen
- Quelle(s) alternative(s) à Google Analytics ?
- Matomo, qu’est ce que c’est ?
  1 – Matomo en version auto-hébergée
  2 – Matomo Cloud (SaaS)
- Pourquoi Matomo ? Ça fonctionne vraiment ?
- Comment installer Matomo sur mon site Drupal et récupérer mes anciennes données ?
- Pour conclure

Est-il encore possible d’avoir une vie privée sur le web ? 

Vous êtes une personne soucieuse de la protection des données personnelles et du respect de l’activité de vos visiteurs sur votre site internet, et vous avez bien raison ! 

Et cela nous importe aussi chez Happyculture. Connaître le trafic sur notre site web c’est important pour mesurer ses performances et l’améliorer, mais pas au détriment de la vie privée.  Utilisateurs de Matomo depuis plusieurs années, en voyant circuler les articles autour de la CNIL et Google Analytics ces dernières semaines, nous nous sommes dit qu’il serait intéressant de vous expliquer pourquoi nous l’avons choisi. 

Mais avant de vous expliquer nos raisons, petit retour en arrière sur les faits.

Google Analytics dans le viseur européen

C’est en 2020 que l’affaire commence. La Cour de Justice de l’Union Européenne (CJUE), considérant que le transfert des données à caractère personnel de l’Union Européenne (UE) vers les Etats-Unis n’est pas conforme aux exigences requises par l’UE, décide d’invalider le Privacy Shield (Bouclier de Protection à mettre en annotation).

Suite à cette décision, NOYB, organisation de la protection de la vie privée fondée par Max Schrems, affirme que le géant de l’analyse d’audience web autorise, et ce de manière illégale, un traitement des données personnelles et leur transfert vers Google, donc vers les États-Unis. En 2021 NOYB dépose alors 101 plaintes auprès de plusieurs autorités de contrôle européennes, dont la CNIL en France. 

En février 2022, la CNIL se prononce et met en demeure des sites français utilisant Google Analytics de mettre en conformité leurs traitements avec le RGPD. 

Comme le sujet est sensible et le positionnement de la CNIL nouveau, la décision de mise en demeure a donné lieu à une vague de questions/réponses que la CNIL a mis en ligne pour partager l’information. Des pistes de solutions y ont été évoquées, comme agir par exemple sur le paramétrage des conditions de traitement de l’adresse IP ou encore utiliser un serveur mandataire ou proxy. Mais pour le moment, ces solutions n’ont pas satisfait la CJUE. 

En attendant que cette situation aboutisse et pour anticiper l’éventuelle illégalité de l’utilisation de Google Analytics, beaucoup ont pris les devants et cherché des remplaçants.

Quelle(s) alternative(s) à Google Analytics ?

Google Analytics reste l’outil d’analyse de trafic web le plus utilisé dans le monde ; plus de 55 % des sites web l’utilisent ce qui représente près de 86 % du marché (source W3Techs).

Heureusement des alternatives existent, et il y a du choix ! 

Nous pouvons citer Matomo bien sûr, mais aussi AT Internet Analytics Suite, Plausible, Open Web Analytics, Content Square, Hotjar, Abla Analytics, Go Squared, Beyable Analytics, etc. 

Certaines solutions, plus respectueuses de la vie privée de leurs utilisateurs et pouvant être exemptées au recueil de consentement, ont été identifiées comme conformes par la CNIL en suivant leurs guides de configuration. Et Matomo en fait partie.

Matomo, qu’est ce que c’est ?

Chez Happyculture, nous avons opté pour Matomo.
Il s’agit d’un outil Open Source gratuit de collecte de statistiques créé en 2007. Matomo vous permet de mesurer l’audience de votre site, comprendre le comportement de vos visiteurs et suivre des conversions. Anciennement connu sous le nom de Piwik, le projet a changé de nom en 2018 pour éviter tout conflit avec d’autres produits. La CNIL a approuvé cet outil au vue des critères RGPD (et sous réserve d’en faire la bonne configuration). Il est utilisé par plus d’un million de sites de toutes les tailles et se revendique comme respectueux de la vie privée de ses utilisateurs.
 

Matomo existe en 2 offres pour répondre à vos objectifs.

1 – Matomo en version auto-hébergée

Avec l’auto-hébergement, vous choisissez comment sont gérées vos données et leur lieu de stockage puisque c’est vous qui en avez la propriété. Aucun serveur tiers ne voit arriver vos données.

2 – Matomo Cloud (SaaS)

Si vous ne pouvez pas ou ne voulez pas en faire l’installation sur l’un de vos serveurs. Vous pouvez opter pour la version hébergée de Matomo dans son cloud allemand pour que vos données restent en Europe.

Vous pouvez comparer les deux versions dans leur grille de fonctionnalités. Les tarifs débutent à 19 euros par mois pour 50 000 hits.

Attention, il peut y avoir des coûts cachés si vous souhaitez activer des fonctionnalités payantes de Matomo présentes dans leur place de marché, vous y découvrirez le coût des extensions associées

Pourquoi Matomo ? Ça fonctionne vraiment ?

Vous nous connaissez, chez Happyculture nous défendons une vision du web respectueuse de ses utilisateurs et utilisatrices et donc de leur vie privée. Nous sommes aussi amoureux de l’open source, ce n’est pas pour rien que nous sommes experts Drupal !

Alors quitte à choisir entre Matomo et Google Analytics, la balance penche assez vite pour le premier lorsque nous devons choisir notre outil de mesure de statistiques. 

Qui dit héberger ses propres données pour mesurer son audience dit critère acceptable pour ne pas afficher de bandeau de cookies ou de demande de consentement (car nos contenus ou le reste de vos intéractions ne déposent pas non plus de cookies hormis l’antispam). 

Au-delà de la bonne idée, peut-on appliquer les mêmes usages si l’on doit changer d’outil ? Comme souvent, “ça dépend” est la réponse qui s’impose. 

Si la majorité des usages de votre outil de statistiques consiste à mesurer le nombre de visites, étudier les pages les plus vues, comprendre le type de visites que vous recevez (périphérique, zone géographique…) et suivre quelques objectifs de conversion, vous pourrez basculer sans crainte et ne serez pas perdus.

Si en revanche vous utilisez des fonctionnalités avancées de Google Analytics de type cohorte, traçage inter périphérique, plan de taggage, analyse par machine learning de vos jeux de données, vous risquez de perdre quelques petites choses.
Cela peut être bloquant pour vous mais mérite de vous interroger sur le besoin de collecter certaines données. 

D’un autre côté Google applique parfois de l’échantillonnage à partir des données qu’il collecte afin de générer vos rapports (sur des grandes masses de données, toutes ne sont pas comptabilisées mais des tendances sont calculées).

Comment installer Matomo sur mon site Drupal et récupérer mes anciennes données ?

Si basculer sur Matomo vous intéresse, l’installation est aussi simple que pour Google Analytics, il vous suffit d’insérer leur code de tracking. Comme ils sont sympas chez Matomo, ils vous expliquent comment migrer vos anciennes données pour assurer une transition en douceur depuis Google Analytics 3. Vous avez aussi un autre exemple en FR si vous préférez.

Notez que pour respecter le RGPD, vous devrez faire quelques configurations documentées par la CNIL. Je vous glisse aussi le lien vers la documentation pour permettre à un utilisateur de couper à la source le suivi dans votre outil de statistiques si vous souhaitez lui en donner la possibilité.

Bonus amical qui vous fera peut être gagner du temps (je parle d’expérience…), lorsque vous faites vos tests, pensez à désactiver votre bloqueur de publicité qui peut considérer votre domaine comme source de publicité à tort. ;-)

Si vous utilisez Drupal 9, vous pouvez insérer Matomo via le module contribué ou comme suit :

Créer le fichier JS qui va insérer le script :

Déclarer une librairie :

Insérer la librairie dans vos pages :

Pour conclure

Vous l’aurez compris, en choisissant Matomo, vous optez pour une solution recommandée par la CNIL et respectueuse du RGPD, la grande contrainte des outils d’analyse d’audience.

Open source, simple et gratuit, il répondra parfaitement à vos besoins principaux d’analyse de votre trafic web si vos usages ne sont pas extrêmement pointus.

La tendance du web étant au respect de la vie privée des personnes, proposer toujours plus de suivi des utilisateurs n’est pas une direction susceptible d’offrir des débouchés satisfaisants. 

Le ciblage des contenus semble en meilleure posture si vous devez proposer de la publicité sur vos contenus.
Le passage à Google Analytics 4 est peut être une piste de réponse mais on ne sait pas si la CNIL l’acceptera (à priori, non). Google restant dans le viseur du législateur, autant ne pas participer à une forme de loterie et anticiper une alternative au plus tôt.

La question de la toute puissance de Google mérite également d’être soulevée. Ce sont nos choix de gestionnaires et sociétés intégratrices de solutions qui lui confèrent sa puissance. Une fois en position de quasi monopole, le jeu de la concurrence ne porte plus ses fruits. Alors il nous incombe de défendre la diversité des choix. Matomo est une option intéressante mais comme indiqué plus tôt, les concurrents ne manquent pas.

Nous terminerons en vous posant cette question, avez-vous toujours une bonne raison de rester sur Google Analytics et de prendre le risque de jouer avec la loi ?

Lors de la réalisation de nos projets nous sommes souvent amenés à réaliser la migration de grandes quantités de contenus afin d'éviter aux personnes en charge de l'administration du site un travail long et fastidieux de copie. De plus, la plupart des projets de cet ordre font le choix de donner accès à ces contenus par l'entremise d'un ou plusieurs moteurs de recherche aux fonctionnalités plus ou moins avancées. Nous sommes donc régulièrement confrontés à la cohabitation entre le module Migrate qui nous permet de gérer l'import massif de contenus depuis des sources variées et le module Search API qui sert de socle à l'indexation de ces contenus dans les moteurs de recherche.

Migrate comme Search API sont deux outils performants dans l'absolu. Cependant, lorsqu'ils sont utilisés ensemble, le temps nécessaire à l'import et l'indexation des contenus monte en flèche et devient rapidement improductif.

Mais qu'est-ce qui se passe ?

Lorsque Migrate enregistre une entité, cela déclenche automatiquement un processus côté Search API qui peut s'avérer assez coûteux en ressources. En effet, ce dernier va charger tous ses index actifs un par un et vérifier s'il a quelque chose à faire puis procéder à l'indexation en elle-même.

La principale piste qui est généralement identifiée pour résorber ce problème est de désactiver l'option "Indexer les éléments immédiatement". Malheureusement, même si cela réduit effectivement le temps nécessaire aux migrations, ce n'est pas suffisant car Search API a tout de même besoin de consigner l'entité qui devra être indexée plus tard. Il charge donc tous les processeurs de tous ses index actifs pour déterminer si cette entité spécifique sera indexée immédiatement, ultérieurement ou pas du tout. Cette option ne permet donc d'économiser que l'étape d'indexation en elle-même ce qui est insuffisant dans le cas de grandes migrations.

Comment se sortir de cette galère ?

Comme dit précédemment, Search API se préoccupe de tous ses index actifs pour déterminer quoi faire avec le contenu migré. La première solution que vous pouvez donc mettre en place est de désactiver les index avant d'exécuter vos migrations. Cela peut être réalisé avec Drush assez facilement via la commande search-api:disable-all (et sa petite sœur search-api:enable-all lorsque les migrations sont terminées) ou encore carrément en désactivant le serveur via la commande search-api:server-disable (et search-api:server-enable). Si vous ne lancez pas vos migrations via Drush, c'est également réalisable par le code mais nous ne couvrirons pas cela dans cet article.

L'avantage de cette méthode est qu'elle remplit l'objectif de performance en désactivant tout le processus de Search API et qu'elle est relativement simple à mettre en œuvre (une commande avant les migrations, une autre après). Elle présente cependant deux inconvénients importants :

1. si le serveur ou les index sont désactivés, Search API ne sait pas qu'une entité a été créée ou modifiée et ne l'indexera donc jamais (il ne faisait pas tout ça pour rien quand il était activé avec l'option d'indexation immédiate désactivée) ;
2. durant toute la durée des migrations, les pages du site s'appuyant sur l'un des index de recherche désactivés ne seront plus accessibles (erreur 500).

Forcer la reconstruction des trackers de Search API

Le premier inconvénient est majeur car cela n'a aucun intérêt d'essayer de résoudre les problèmes de performance de nos migrations si le contenu n'est plus jamais présenté dans les moteurs de recherche. Comme évoqué, cet inconvénient est dû au fait que Search API maintient une liste des contenus qu'il a indexé ou qu'il doit indexer dans la table search_api_item de la base de données. On appelle cette liste son tracker. Lorsque les index sont désactivés, le tracker n'est pas mis à jour et Search API ne sait donc pas qu'il a quelque chose à faire avec ces entités.

Une fois encore, Drush nous facilite la vie en exposant la commande search-api:rebuild-tracker qui, comme son nom l'indique, va imposer à Search API de reconstruire le tracker de ses index et donc de découvrir toutes les entités dont il n'avait pas connaissance auparavant.

Éviter l'indisponibilité des index Search API durant la migration

La seconde problématique n'en est une que si vous avez des migrations qui s'exécutent alors que le site est accessible. Si vos migrations ne font partie que d'un lot joué une seule fois avant la mise en production, cette section ne vous intéresse pas forcément… Cela dit, la solution est tellement simple que cela pourrait vous convaincre davantage que de désactiver les index.

En effet, pour que les index ne soient pas inaccessibles pendant la migration, il suffit de ne pas les désactiver !

Si vous avez suivi depuis le début, vous vous rappelez que l'on a désactivé les index pour que Search API ne perde pas de temps à déterminer s'il faut oui ou non indexer chaque entité que vous importez. Donc si nous les réactivons nous retombons sur le problème de performances que l'on essaie de résoudre ! C'est sans compter une fonctionnalité non documentée de Search API : le paramètre search_api_skip_tracking !

Pour comprendre ce qu'il se passe dans le moteur de Search API, cherchons à comprendre à quel endroit il intervient dans le code. Connaissant un peu la façon dont Drupal est conçu nous pouvons imaginer deux méthodes : un hook ou un événement. Les événements liés à la modification d'une entité n'étant pas courants dans la version actuelle de Drupal, nous allons commencer par nous pencher sur les hooks. Étant donné que c'est une fonctionnalité de bas niveau de Search API, s'il y a un hook il sera situé dans le module search_api et pas l'un de ses sous-modules. De plus, Search API peut indexer tout type d'entité et il est donc peu probable qu'il s'agisse d'une implémentation d'un hook spécifique à un type d'entité donné. Nous allons donc pouvoir chercher dans la base de code une fonction dont le nom commence par search_api_entity_ ce qui nous laisse peu de choix : search_api_entity_delete, search_api_entity_insert, search_api_entity_update, search_api_entity_view et search_api_entity_extra_field_info. Bingo ! Les trois premiers concernent des opérations de création, modification et suppression d'entités génériques.

Lorsque l'on prend une de ces fonctions et que l'on regarde ce qu'il s'y passe en détail, on constate l'appel au service search_api.entity_datasource.tracking_manager et plus spécifiquement à ses méthodes entityInsert, entityUpdate et entityDelete. Chacune d'entre elles teste très rapidement la valeur d'un paramètre search_api_skip_tracking de l'entité et, s'il n'est pas vide, interrompt son exécution.

Sachant donc que cette valeur permet d'arrêter Search API avant qu'il ne consomme des ressources, nous pouvons l'ajouter à notre entité en cours de migration. C'est d'ailleurs très facile car Migrate ne se préoccupe pas vraiment de savoir si une donnée que l'on passe dans son mapping existe ou pas. Il est donc possible d'ajouter une entrée dans les process de nos migrations comme suit :

Bien évidemment, ceci a pour effet de totalement contourner Search API et il est donc toujours nécessaire de reconstruire ses trackers après la migration comme vu au chapitre précédent.

Le plus simple pour la fin

Maintenant que les contenus ont été importés et que les trackers ont été reconstruits il ne reste plus qu'à indexer tout le contenu pour qu'il devienne disponible sur le site. Une fois encore Drush nous facilite la vie en nous permettant d'accéder à la commande search-api:index mais vous pouvez également passer par l'interface d'admin de Search API si vous préférez.

En résumé

1. injectez la donnée search_api_skip_tracking dans vos entités via Migrate (ou désactivez vos index mais franchement ça vaut pas le coup) ;
2. reconstruisez les trackers une fois vos migrations terminées via drush search-api:rebuild-tracker ;
3. n'oubliez pas d'exécuter l'indexation manuellement une fois les trackers reconstruits via drush search-api:index ;
4. attendez patiemment le prochain article en vous hydratant bien et en prenant soin de votre santé physique et mentale.

Voilà ! Maintenant vous savez comment faire lorsque vous avez à combiner migrations et indexation. Vous vous apercevrez lorsque vous y serez confrontés que l'indexation en elle-même peut prendre un très long temps et même ralentir au fil de son exécution. C'est une problématique a priori liée à la mémoire disponible mais cela fera l'objet d'un prochain article (plus court, c'est promis) !

Vous venez de créer un nouveau type d'entité. Vous contemplez votre œuvre, réfléchissant à la prochaine touche à ajouter pour la parfaire. Tout à coup, un éclair vous frappe : "Il nous faut prendre en charge les alias Pathauto". Évidemment ! Pourquoi se priver de la puissance de cet outil ? C'est l'un des modules indispensables de Drupal 9 qui vous permet d'améliorer la qualité de votre référencement (du SEO éthique et responsable bien sûr !). Comme il est 16h et que la fin de journée approche, vous espérez pouvoir boucler ça rapidement pour reprendre votre marathon visionnage de l'intégrale de Columbo au plus vite.

Scénario 1 : Je suis une personne chanceuse

L'accident heureux consiste à vous rendre dans l'interface de Pathauto et de voir si votre type d'entité n'est pas déjà visible. Si tel est le cas, vous aurez le temps de vous faire un épisode de plus car la journée est terminée, cela fonctionne. Pour les gens moins chanceux, voici ce qu'il faut faire pour que cela fonctionne.

Scénario 2 : J'ai besoin de débrider le chemin de chaque entité

L'intérêt d'un système de gestion de contenu est de maîtriser les URLs de ses contenus. Vous pouvez opter pour de la génération automatique mais vouloir débrider cette génération entité par entité (comme pour les nœuds).

Pathauto est pré-configuré pour prendre en charge n'importe quel type d'entité. La magie se passe dans \Drupal\pathauto\Plugin\Deriver\EntityAliasTypeDeriver::getDerivativeDefinitions(). Trois critères sont à respecter pour que cela fonctionne clé en main.

1. Votre type d'entité doit déclarer un template de lien "canonical".

2. Votre type d'entité doit être fieldable.

3. Votre bundle doit avoir un champ "path" qui stockera le chemin vers l'entité pour les cas où vous voulez débrider.

Si vous remplissez ces trois critères, votre type d'entité est maintenant pleinement utilisable dans Pathauto. Vous pouvez fermer votre CMS préféré et retourner à votre visionnage, vous n'avez raté que la première moitié de l'épisode.

Scénario 3 : Je n'ai pas de champ "path" ou n'en ai pas besoin

Si le champ "path" peut être intéressant dans certains cas, il arrivera que vos types d'entités soient plus basiques. Dans ce cas, comment l'exposer à Pathauto ? Il y a un petit peu plus de travail mais rien d'insurmontable. La solution consiste à implémenter un plugin AliasType. (Si vous ne savez pas comment fonctionnent les plugins, je vous invite à relire notre article). N'oubliez pas de déclarer son annotation @AliasType.

Les deux attributs de l'annotation à regarder de près sont types qui liste des types d'entités pour lesquels votre plugin va s'appliquer et context_definitions qui permet d'accéder à la liste des tokens de votre type d'entité (et donc ses champs, ses métadonnées et toutes les fonctionnalités avancées de Pathauto).

Ne vous précipitez pas tout de suite sur la génération de vos alias car vous risquez d'être déçu(e). La configuration est possible mais il reste une étape importante pour pouvoir profiter de tout cela, déclencher la génération. Si l'on ne donne pas un coup de pouce au système, la génération de vos alias ne se fera jamais. Pathauto implémente les hook_entity_OP() pour déclencher la génération mais si vous n'avez pas de canonical ou de champ path comme évoqué précédemment, vous devrez déclencher vous même le générateur.

Les alias doivent se créer, se mettre à jour et se supprimer en fonction de l'opération effectuée sur votre entité, vous allez donc devoir implémenter vous aussi les hook_entity_OP(). Comme on cible un type d'entité précis, les hooks à implémenter sont hook_ENTITY_TYPE_OP(). Cela donne ce code :

Une fois vos hooks implémentés, vous devriez pouvoir tester la génération des alias et si tout s'est bien passé, cela devrait fonctionner.

Bonus : générer en masse les alias

Il vous reste une dernière action à faire si voulez bénéficier de la génération en masse des alias. Il faut implémenter la méthode \Drupal\mobility_plans\Plugin\pathauto\AliasType\MobilityPlanAliasType::bulkUpdate() dans votre plugin d'alias.

Et nous y voilà ! À vous les alias finement ciselés pour parfaire votre chef d'œuvre ! Vous pouvez commiter tout cela et retourner prendre des nouvelles de Peter Falk, il est sur le point d'attraper le meurtrier et résoudre l'enquête.

Mais c’est quoi un CMS ?

Un CMS, ou SGC en français, est un logiciel ou une plateforme permettant de créer et modifier facilement le contenu qui alimente un site internet. Le contenu peut être généré par une personne seule ou une équipe de webmasters mais il est également possible de laisser les visiteurs publier leur propre contenu. On parle dans ce cas de contenu généré par les utilisateurs (UGC).

Le CMS est protéiforme, il peut gérer votre site institutionnel, votre boutique en ligne, votre blog, votre médiathèque, votre site d’offres d’emploi.... Bien configuré, il peut propulser des sites allant d’une dizaine de visiteurs jusqu’à plusieurs dizaines de milliers par jour.
Un système de gestion de contenu est dans sa zone de confort pour la saisie, la validation, la classification, la gestion de médias, la configuration du référencement (SEO), l’attribution de rôles/droits à des utilisateurs(rices), l’agrégation, la navigation au sein de ces contenus...

Les CMS ne sont bien sûr pas la seule solution pour créer un site, mais ils sont accessibles et possèdent une base de fonctionnalités déjà existantes et suffisamment complètes. En optant pour un CMS, vous avez déjà un panel de fonctionnalités à votre disposition.

Le CMS peut être open source (Drupal, Wordpress, Prestashop…) ou propriétaire (Sitecore, Kentico, Adobe site manager...). Selon votre choix, des coûts de licence peuvent s’appliquer et votre niveau d’autonomie pour modifier / voir sous le capot varie très fortement.
À l’heure où les supports et canaux se multiplient pour se spécialiser (applications mobiles, réseaux sociaux, site institutionnel, site RH, site du support utilisateurs…), une constante est toujours présente : le besoin de rédiger votre contenu ! Vous avez donc toujours un intérêt à avoir un système de gestion de contenu au sein de votre structure.

Le marché tend à se rapprocher du modèle suivant : vous créez un site dédié à l’administration de votre contenu pour centraliser votre contenu et vos sites / applications se connectent à ce système de gestion de contenu pour présenter les bons contenus au(x) bon(s) endroit(s). Grâce à cette mutualisation vous simplifiez la mise à jour de l’information en évitant la répétition.

Faites votre choix

Chaque structure a ses propres besoins et le modèle décrit ci-dessus ne s’applique pas forcément à votre organisation. Rassurez-vous, il existe des solutions pour chaque taille de structure / projet. Passons en revue vos options de la moins onéreuse à la plus onéreuse.

Nous ne vous détaillerons pas ici, ni ailleurs, les avantages et inconvénients de chacun des logiciels car il en existe plusieurs dizaines dans chaque langage (PHP, Python, Ruby…). De plus, nous estimons que seule l’expérience d’utilisation et la mise en œuvre de ces outils permettrait de donner un avis objectif et légitime. Ce n’est pas notre cas, nous sommes experts Drupal.

À noter que nous mentionnons le terme de réversibilité dans les 3 options, ce terme désigne la capacité à repartir avec le code de votre site et vos contenus pour pouvoir les mettre chez un autre prestataire / hébergeur et les modifier.
 

Option 1 : Un site générique, hébergé sur une plateforme SaaS

Ce peut être l’offre de votre hébergeur type Ionos (1&1) ou un service dédié type Wix, Hubside. Il existe aussi des services spécialisés si vous voulez monter une boutique par exemple : Squarespace ou Shopify sont les services les plus connus.

Pour quelques euros par mois vous pouvez choisir parmi une collection de gabarits et ambiances visuelles celui qui vous plaît pour ensuite modifier le contenu des pages.
Les possibilités de personnalisation sont très limitées mais pour un site simple (type plaquette), cette option fait le travail. Vous n’avez pas à vous préoccuper de la maintenance, de l’hébergement, des sauvegardes. Tout est compris dans l’offre.

La contrepartie est que vous ne pourrez pas transformer le site pour en faire ce que vous voulez si le site doit évoluer au bout de quelques mois ou années. Vous ne pourrez pas non plus repartir avec le code source du site (réversibilité) pour l’héberger ailleurs ou le faire modifier par un(e) développeur(se). C’est la plateforme sur laquelle vous créez votre site qui est propriétaire de vos données.

Le coût de ces services est très accessible :

• Coût de la conception et du développement : Gratuit si vous le faites vous même. Quelques centaines d’euros si vous passez par un prestataire.
• Adaptabilité aux besoins métiers : Inexistante
• Coût récurrent tout au long de la vie du site : 
  • Licence : Entre 1 et 50 € par mois pour le service
  • Hébergement : Compris
  • Maintenance : Compris
• Personnalisation à votre image de marque : Inexistante à Faible
• Connaissances techniques requises : Aucune
• Réversibilité : Impossible

Option 2 : Un site sur mesure à partir d’un CMS

Si vous souhaitez un site qui reflète fidèlement votre identité visuelle et pour lequel l’expérience de navigation est taillée sur mesure pour vos contenus, alors le site hébergé sur une plateforme tierce ne conviendra pas. Vous aurez besoin de gérer votre site en autonomie.

Selon que vous possédiez les compétences au sein de votre structure ou via un prestataire type agence web (tel qu’Happyculture ;-)), les étapes de conception de l’interface (Design / Responsive), l’organisation de la circulation au sein des pages (ergonomie et organisation de l’information) et le développement seront des passages obligés pour rendre du mieux possible un service à vos visiteurs.

Pour construire ce site sur mesure, plutôt que de partir d’une feuille blanche, le CMS est l’outil nécessaire à votre projet pour les raisons mentionnées précédemment.
Avec un CMS vous partez d’un socle de fonctionnalités extensible. L’équipe technique se charge de configurer et enrichir ce socle en piochant dans la bibliothèque de modules complémentaires gratuits ou payants. Si vos besoins sont pointus et non couverts par un module complémentaire, les développeurs peuvent créer des fonctionnalités sur mesure. Dans certains cas, il pourra être nécessaire de déconstruire certaines fonctionnalités pour les redévelopper si le comportement par défaut ne vous convenait pas (ex : recherche de contenu sur mesure).

Drupal dispose de milliers de modules complémentaires centralisés sur le site officiel drupal.org. Cela permet de garantir la couverture par son équipe de sécurité et vous protéger d’éventuelles attaques ou fuites de données (si votre site applique les mises à jour (!)). Les modules sont développés par la communauté, 85% par des personnes payées pour le faire, 15% par des bénévoles.

Pour maîtriser votre image de marque et l’organisation de votre contenu votre site devra donc être hébergé sur vos serveurs ou chez un hébergeur. Selon la taille du site, le coût varie de quelques dizaines à quelques centaines d’euros par mois.

Il faudra ajouter à cela une ligne budgétaire dédiée à la maintenance du site. Qu’elle soit corrective ou évolutive, votre site vit au-delà de sa mise en ligne initiale. Des failles de sécurité peuvent être découvertes et votre site doit être mis à jour pour que vous restiez protégés. Des bugs peuvent également être corrigés par la communauté qui développe ces modules et vous en faire bénéficier gratuitement en appliquant ces mises à jour.

Pour résumer, vous êtes pleinement propriétaires de votre site, vous maîtrisez la mise en forme, l’organisation du contenu. 

Le coût de la conception et du développement représentent l’essentiel de la création du site mais permettent de se distinguer de ses concurrents et de garantir une réponse aux besoins de vos visiteurs.

• Coût de la conception et du développement : Plusieurs milliers à dizaines de milliers d’euros selon la taille du site
• Adaptabilité aux besoins métiers : Moyenne
• Coût récurrent tout au long de la vie du site : 
  • Licence : 0 € pour les CMS open source
  • Hébergement : À partir de 50 € par mois
  • Maintenance : À partir de 100 € par mois pour une version minimale (correctifs de sécurité), plus si on ajoute des correctifs autres + des évolutions
• Personnalisation à votre image de marque : Totale
• Connaissances techniques requises : Une équipe technique interne ou un prestataire est indispensable
• Réversibilité : Possible (peut dépendre du contrat, pensez à vérifier !)

Option 3 : Un site sur mesure à partir d’une page blanche

La troisième et dernière option qui s’offre à vous et votre équipe technique est l’utilisation d’un Framework (Symfony, Express, Django, Ruby on Rails…). Un framework est une boîte à outils qui permet à l’équipe technique de construire un outil personnalisé de A à Z. Vous tirerez les mêmes bénéfices que l’option 2 et irez plus loin dans la personnalisation en imaginant également la partie administration du site sur mesure.

Ce cas peut être intéressant pour des sites qui comportent une partie “métier” forte qui ne peut pas être réalisée via des modules complémentaires et le cœur d’un CMS ou qui nécessiteraient beaucoup de développements sur mesure.

Cette solution d’une certaine façon implique de réinventer la roue pour la saisie et l’administration des contenus car toutes les fonctionnalités de saisie du contenu et d’administration doivent être développées, là où le CMS propose une solution clé en main. C’est autant de budget en plus à y dédier.

Les avantages du Framework comparés au CMS sont faibles, le seul cas qui justifiera le surcoût sera l’intégration de nombreuses fonctionnalités métier.

• Coût de la conception et du développement : Plusieurs milliers à dizaines de milliers d’euros selon la taille du site
• Adaptabilité aux besoins métiers : Totale
• Coût récurrent tout au long de la vie du site :
  • Licence : 0 €
  • Hébergement : À partir de 50 € par mois
  • Maintenance : À partir de 100 € par mois pour une version minimale (correctifs de sécurité), plus si on ajoute des correctifs autres + des évolutions
• Personnalisation à votre image de marque : Totale
• Connaissances techniques requises : Une équipe technique interne ou un prestataire est indispensable
• Réversibilité : Possible (peut dépendre du contrat, pensez à vérifier !)

Conclusion

Voici un tableau récapitulatif des différents critères que nous vous avons présentés ci-dessus.

Avec toutes ces informations, nous espérons que vous y voyez plus clair sur l’intérêt d’un CMS et les situations où il est adapté.

Si vous comptez lancer un projet ou souhaitez des conseils sur l’organisation de votre contenu, n’hésitez pas à nous transmettre vos questions.

Depuis la sortie de Drupal 8, composer est devenu la façon la plus répandue de gérer les dépendances des projets. Ainsi, nous pouvons charger modules contribués et thèmes de façon unifiée ainsi que, si nécessaire, les librairies PHP dont ils dépendent. Cependant, certains modules ont besoin de librairies venant du monde du front et n'étant pas nativement supportées par composer. Ainsi, pour chacun de ces modules, il est nécessaire d'aller télécharger la librairie manuellement et de l'ajouter dans son dépôt de code. Il faut ensuite suivre régulièrement les mises à jour de toutes les librairies de tous les projets et les télécharger de nouveau en cas d'évolution ou de faille de sécurité.

Ça, c'était avant.

Cela fait bien longtemps maintenant que cette problématique a été résolue par les personnes travaillant sur le front des projets via divers package managers comme npm et bower, dont composer est d'ailleurs inspiré. Mais alors, pourquoi est-ce si compliqué de gérer ces librairies dans Drupal ?

npm, bower et composer ne référencent pas les mêmes types de paquets. En effet, les paquets PHP n'ont pas la même organisation et le même usage que les paquets Javascript. Cependant, même s'il est techniquement possible de déclarer un paquet Javascript dans packagist (la base de données alimentant composer), les auteurs de ces paquets ne le font généralement pas pour ne pas avoir à gérer tous les gestionnaires de paquets du monde et parce que cela n'est généralement pas pertinent pour l'usage que l'on peut faire de leur outil. Les personnes maintenant des outils Javascript se concentrent donc sur npm et bower, les deux plus utilisés.

Bienvenue Asset Packagist

La communauté étant pleine de ressources, le projet Asset Packagist a émergé pour répondre à ce besoin. Son but, mettre à disposition les paquets présents sur npm et bower via composer à moindre effort. Ainsi, il est possible de récupérer ces dépendances et de les maintenir à jour de la même façon que le reste de nos modules.

composer étant configuré pour uniquement chercher ses paquets sur son propre packagist, nous allons devoir tout de même procéder à quelques configurations dans notre projet pour pouvoir utiliser Asset Packagist comme source, suivez le guide !

Configurer le repository

Comme lorsque l'on souhaite pouvoir récupérer les modules et thèmes de Drupal, nous devons déclarer un repository spécifique au sein de notre fichier composer.json. Voilà à quoi ressemble la section repositories de mon fichier :

Désormais, vous avez la possibilité de récupérer les dépendances front de vos modules via les commandes composer require npm-asset/PAQUET ou composer require bower-asset/PAQUET en cherchant sur le site d'Asset Packagist le nom correspondant.

Cependant, en l'état nos dépendances seront installées dans le dossier /vendor, comme les dépendances PHP, ce qui ne nous arrange pas puisque les modules les chercheront dans le dossier /libraries pour les rendre accessibles aux visiteurs.

Configurer l'emplacement des librairies

Pour faire en sorte que composer place les fichiers à l'endroit voulu, il nous faut exploiter les possibilités offertes par le paquet composer/installers. Si ce dernier n'est pas déjà installé dans votre projet (ce qui est peu probable si vous gérez vos modules via composer), il vous suffit de taper la commande composer require composer/installers pour ajouter la dépendance.

Ensuite, il faut ajouter quelques informations dans la section extra de votre composer.json.

• L'entrée installer-types permet de déclarer les types de paquets en provenance de Asset Packagist.
• L'entrée installer-paths permet de déterminer l'endroit où chaque type de paquet sera déposé. Dans le code ci-dessous, les déclarations ont été ajoutées à celles de Drupal.

Et voilà, votre projet est prêt à recevoir ces dépendances et à les maintenir à jour suivant le même processus que vos modules et vos thèmes !

Du 15 au 17 février aura lieu l'édition 2019 du Drupalcamp national. La ville qui l'accueillera sera Paris.

Pour cette année, Happyculture sera bien représentée car tous nos experts Drupal y seront présents. Guillaume Bec y présentera une session sur le RGPD, Julien Dubois viendra témoigner aux côtés de Denis Pitzalis de la mise en œuvre de Drupal à l'UNESCO, Nicolas Meyer et Edouard Cunibil seront quant à eux probablement toujours à proximité des salles de sprint afin de corriger quelques bugs récalcitrants du cœur.

Nous avons le plaisir d'être les sponsors du café pour ces 3 jours de conférence. Vous pourrez donc rester éveillés grâce à nous !

N'hésitez pas à passer une tête pour saluer l'équipe, il reste des places disponibles. Jetez un œil au programme si vous ne l'avez pas encore fait.

Photo d'illustration : frank.meffert.photography CC 2.0 BY

Le besoin fonctionnel à l'origine de ce développement est relativement simple et se retrouve dans de nombreux projets : nous souhaitons pouvoir faire apparaître sur tout notre site un bandeau qui permettra de mettre en valeur, de façon bornée dans le temps, une information importante. Un peu d'analyse autour de cette demande nous permet de la détailler comme suit.

Une personne en charge du contenu du site doit pouvoir activer et configurer une annonce, qui apparaîtra toujours au même emplacement sur toutes les pages du site. La configuration doit permettre de choisir une date de démarrage et une date de fin d'apparition de l'annonce ainsi que son contenu.

Côté technique, la lecture de ce type de besoin soulève deux problématiques pour lesquelles il nous faudra faire preuve de vigilance :

1. puisque cet élément est administrable, il faut qu'une interface facile d'accès et sécurisée soit mise en place ;
2. puisque cette annonce va apparaître et disparaître sans nécessaire action humaine, il faut se méfier des problématiques liées au cache.

Saisie et stockage du contenu

En premier lieu, nous devons donc déterminer la manière dont sera stocké ce contenu car c'est de cela que découlera la façon dont il sera saisi. Plusieurs options s'offrent à nous :

• une entité de contenu personnalisée,
• un objet de configuration simple,
• un bloc personnalisé,
• un système de stockage à plat.

Choisir la bonne option

Puisque le besoin fonctionnel ne demande qu'à ce qu'une annonce soit configurée à la fois, l'utilisation d'une entité de contenu personnalisée semble un petit peu exagérée. En effet, générer une telle entité demande beaucoup de code (bien que l'on puisse utiliser un générateur pour aller plus vite) et nécessitera la création d'au moins une table dans la base de données, de nombreuses routes et contrôleurs pour l'administration. Cela aurait été tout à fait justifié s'il avait fallu pouvoir gérer plusieurs annonces à la fois mais dans notre cas cela représente trop de complexité.

Un objet de configuration simple pourrait également remplir son rôle pour le stockage mais, étant donné qu'il s'agit de permettre à la personne en charge du contenu de mettre en place cette annonce, nous ne conserverons pas cette option. En effet, nos procédures de déploiement provoquent par défaut un écrasement de la configuration de la production au profit de celle versionnée par l'équipe. Bien qu'il soit possible de préserver un ensemble d'objets de configuration lors d'un import, afin d'éviter à la personne en charge du contenu de perdre le fruit de son travail, cela nécessite d'y consacrer du temps et d'ajouter des modules au cœur. Dans le cadre de cette demande, nous avons d'autres options qui nous semblent plus judicieuses.

Un bloc personnalisé, basé sur un type de bloc spécialement conçu pour l'occasion, pourrait bien être une réponse pour sa simplicité de configuration et la mise à disposition d'une interface d'édition similaire à celle d'un nœud. Cette solution, bien que très alléchante, nous pose trois problèmes majeurs. Tout d'abord, nous n'avons pas le module Block Content actif sur notre site, ce qui signifie que nous ne l'activerions que pour un seul type de bloc qui ne contiendrait lui-même qu'un seul bloc. Deuxièmement, pour permettre à la personne en charge du contenu de modifier les champs de ce bloc, il aurait été nécessaire d'intégrer un module de la communauté supplémentaire, sinon elle aurait également pu modifier toute la configuration de tous les blocs. Enfin, la gestion très spécifique du cache dont nous avons fait mention précédemment aurait nécessité d'altérer en profondeur le fonctionnement des blocs personnalisés, ce qui nous semblait, une fois de plus, très disproportionné par rapport à la demande.

Finalement, c'est donc un système de stockage à plat, dans la State API, qui nous semble la meilleure option. En effet, le contenu de la State API est indépendant de la configuration et spécifique à l'environnement sur lequel il est défini. Son accès est très rapide et il ne nécessite aucune configuration particulière ni aucun module complémentaire. Son seul défaut par rapport aux entités de contenu personnalisées ou aux blocs personnalisés, c'est qu'il faut manuellement créer le formulaire qui permettra d'administrer l'annonce. Notez que cette option n'est viable que parce que les données que nous souhaitons stocker ne sont pas critiques pour le fonctionnement du site. Dans le cas contraire, conformément à ce qui est indiqué dans la documentation officielle, il nous aurait fallu trouver une autre solution.

Route et permissions

Entrons dans le vif du sujet ! Pour tout le code qui va suivre, il est important de noter qu'il prend place dans un module nommé hc_announce ; le namespace racine de tous les objets sera donc \Drupal\hc_announce et le nom du module sera utilisé, autant que possible, en préfixe de tous les noms machines qui pourraient entrer en collision avec d'autres modules.

En règle générale, je commence toujours par me poser la question des permissions. Dans notre cas, je souhaite pouvoir assigner le droit de modifier l'annonce indépendamment de toutes les autres permissions du site. Je vais donc créer un fichier hc_announce.permissions.yml contenant le code suivant :

administer announcement:
  title: 'Administer announcement'
  description: 'Allow to access the announcement settings form'

Ensuite, je passe à la route d'accès au formulaire, dans le fichier hc_announce.routing.yml j'ajoute l'entrée :

hc_announce.announcement_settings_form:
  path: '/admin/config/announcement'
  defaults:
    _form: '\Drupal\hc_announce\Form\AnnouncementSettingsForm'
    _title: 'Announcement settings'
  requirements:
    _permission: 'administer announcement'

Puis, comme je suis un peu perfectionniste et que je pense aux personnes en charge du contenu, j'ajoute cette route dans le menu d'administration grâce à une entrée dans le fichier hc_announce.links.menu.yml :

hc_announce.announcement_settings_form:
  title: Announcement
  parent: system.admin_config
  description: 'Announcement settings.'
  route_name: hc_announce.announcement_settings_form

Le lien "Announcement" apparaîtra donc dans le menu d'administration sous l'entrée "Configuration" matérialisée par la route parente system.admin_config.

Si vous voulez en savoir plus sur le fonctionnement des routes de Drupal 8, je vous renvoie à un ancien article issu de notre formation.

La base du formulaire

Ces actions préparatoires terminées, il est temps de passer aux choses sérieuses, le formulaire en lui même.

Il nous faut récupérer une date de début, une date de fin, un titre et un message au minimum. Pour des soucis pratiques, nous ajouterons un système pour activer ou désactiver l'annonce rapidement (c'est à dire sans avoir à jouer avec les dates). Pour clarifier l'utilisation de ce formulaire, nous n'afficherons les champs utiles que si la case à cocher pour activer l'annonce est cochée. C'est parti !

Nous créons donc le fichier src/Form/AnnouncementSettingsForm.php dans notre module avec le minimum pour que cela soit considéré comme un formulaire valide :

namespace Drupal\hc_announce\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

/**
 * Class AnnouncementSettingsForm.
 */
class AnnouncementSettingsForm extends FormBase {

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'announcement_settings_form';
  }

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {

    $form['submit'] = [
      '#type' => 'submit',
      '#value' => $this->t('Submit'),
    ];

    return $form;
  }

  /**
   * {@inheritdoc}
   */
  public function submitForm(array &$form, FormStateInterface $form_state) {
    $this->messenger()->addStatus($this->t('The configuration options have been saved.'));
  }

}

Le résultat n'est pas encore exceptionnel mais il nous permet de valider que la route pointe bien sur notre classe.

L'étape suivante consiste à étoffer la méthode buildForm() pour afficher tous les champs dont nous avons besoin.

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {

    $form['enabled'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Enable announcement'),
      '#default_value' => FALSE,
    ];

    $form['announcement'] = [
      '#type' => 'details',
      '#title' => $this->t('Announcement settings'),
      '#open' => TRUE,
      '#states' => [
        'visible' => [
          ':input[name="enabled"]' => ['checked' => TRUE],
        ],
      ],
    ];
    $form['announcement']['start_date'] = [
      '#type' => 'date',
      '#title' => $this->t('Start date'),
      '#default_value' => '',
      '#required' => TRUE,
    ];
    $form['announcement']['end_date'] = [
      '#type' => 'date',
      '#title' => $this->t('End date'),
      '#default_value' => '',
      '#required' => TRUE,
    ];
    $form['announcement']['title'] = [
      '#type' => 'textfield',
      '#title' => $this->t('Announcement title'),
      '#default_value' => '',
      '#maxlength' => 64,
      '#size' => 64,
    ];
    $form['announcement']['announcement'] = [
      '#type' => 'text_format',
      '#title' => $this->t('Announcement'),
      '#default_value' => '',
      '#required' => TRUE,
      '#format' => 'full_html',
    ];
    $form['submit'] = [
      '#type' => 'submit',
      '#value' => $this->t('Submit'),
    ];

    return $form;
  }

Ce qui nous donne un résultat déjà plus proche de nos besoins.

Validation de la saisie

La magie de Drupal fait que les champs marqués comme required seront validés automatiquement, de même que les données relatives aux types de champs auront leur format vérifié avant soumission. Il ne nous reste qu'à vérifier que la date de fin est bien postérieure à la date de début et nous allons pour cela implémenter la méthode validateForm().

  /**
   * {@inheritdoc}
   */
  public function validateForm(array &$form, FormStateInterface $form_state) {
    $values = $form_state->getValues();
    if ($values['end_date'] < $values['start_date']) {
      $form_state->setErrorByName('end_date', $this->t('The ending date must be greater or equal than the starting date.'));
    }
  }

Le résultat avec le module du cœur Inline Form Error actif (vous devriez activer ce module sur tous vos projets par défaut) est plutôt sympa.

Enregistrement et injection de dépendances

Pour finir, il va nous falloir enregistrer l'information dans la State API et nous assurer que le formulaire tiendra compte des données existantes lors de son prochain affichage. Contrairement aux formulaires de configuration qui proposent un ensemble de méthodes pour accéder aux objets de configuration, nous ne disposons d'aucune aide pour accéder à la State API. Pour y parvenir, nous pourrions faire appel directement à l'objet \Drupal qui contient toutes les méthodes d'assistance nécessaires mais, puisque nous aimons le travail bien fait et le respect des bonnes pratiques, mais aussi dans l'intérêt de l'exercice, nous allons faire appel à l'injection de dépendances.

Dans le cas d'un formulaire qui étend la classe FormBase, nous n'avons pas besoin de spécifier que nous souhaitons implémenter l'interface ContainerInjectionInterface car c'est déjà fait dans la hiérarchie de classe. Il nous suffit donc d'implémenter la méthode statique create() et de spécifier le constructeur de notre objet.

namespace Drupal\hc_announce\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\Core\State\StateInterface;

/**
 * Class AnnouncementSettingsForm.
 */
class AnnouncementSettingsForm extends FormBase {

  /**
   * @var \Drupal\Core\State\StateInterface
   */
  protected $state;

  /**
   * Constructs a new AnnouncementSettingsForm object.
   *
   * @param \Drupal\Core\State\StateInterface $state
   */
  public function __construct(StateInterface $state) {
    $this->state = $state;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container) {
    return new static(
      $container->get('state')
    );
  }

// [...]

Le service de construction de formulaire, sachant que notre classe implémente ContainerInjectionInterface, instanciera notre objet par l'intermédiaire de sa méthode create(), en lui fournissant le conteneur de services en paramètres. C'est cette méthode qui créera l'instance du formulaire à proprement parler en lui fournissant les services dont elle a besoin pour fonctionner, dans notre cas, la State API.

Maintenant qu'on a notre service à disposition, rien n'est plus simple que de stocker les données saisies. Il nous faut juste un peu enrichir la méthode submitForm().

  /**
   * {@inheritdoc}
   */
  public function submitForm(array &$form, FormStateInterface $form_state) {
    $values = $form_state->getValues();

    $this->state->set('hc_announcement', [
      'enabled' => $values['enabled'],
      'start_date' => $values['start_date'],
      'end_date' => $values['end_date'],
      'title' => $values['title'],
      'announcement' => $values['announcement'],
    ]);

    $this->messenger()->addStatus($this->t('The configuration options have been saved.'));
  }

En faisant le choix de ne pas filtrer les données saisies, notamment pour le titre qui est un champ texte simple, nous gardons en tête qu'il faudra être vigilants lors de leur affichage. Heureusement, Twig est là pour nous aider à éviter les failles XSS ! Nous y reviendrons dans la seconde partie de cette série.

La dernière chose à faire est d'enrichir la méthode buildForm() pour afficher les données enregistrées dans la State API lors de l'affichage du formulaire. Je vous épargne la totalité du code pour vous montrer uniquement l'exemple sur le champ "enabled" :

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    $config = $this->state->get('hc_announcement');

    $form['enabled'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Enable announcement'),
      '#default_value' => !empty($config['enabled']) ? $config['enabled'] : FALSE,
    ];

// [...]

Lorsque vous repasserez sur tous les champs pour utiliser les valeurs stockées, n'oubliez pas le #format du champ "announcement".

Et voilà le travail !

Voilà déjà une bonne chose de faîte ! Dans la prochaine partie de cet article, nous aborderons l'affichage de ces données en front et la gestion du cache.

À très bientôt !

Crédit photo de couverture : Sue Cro

Toujours dans les temps, la nouvelle version mineure de Drupal, 8.4.0, est disponible depuis le 4 octobre 2017. Pour la première fois depuis deux ans, cette mise à jour contient des éléments qui pourront casser la rétrocompatibilité de certains sites. Comme pour la sortie des précédentes versions mineures de Drupal, et notamment la mise à jour vers Drupal 8.3.0, cet article vous dévoilera les détails des changements apportés ces six derniers mois.

Attention à la rétro-compatibilité des dépendances (librairies) !

La technologie progresse et l'équipe de maintenance du cœur doit faire des choix pour concentrer les efforts de la communauté sur des tâches à valeur ajoutée pour l'avenir. Parfois, il s'agit simplement de faire des arbitrages entre des fonctionnalités fondamentales pour l'avenir et la compatibilité avec des choix ou projets passés. Pour la première fois depuis la sortie de Drupal 8, cette version mineure introduit des changements qui pourraient poser des problèmes de compatibilité avec certains projets existants. Il est donc demandé à toutes les personnes en charge de la maintenance d'un site Drupal 8 d'être extrêmement vigilantes lors du passage à la 8.4.

Arrêt du support de Internet Explorer 9 et 10

Depuis avril 2017 Microsoft a arrêté le support de Internet Explorer 9 et 10. Ces vielles versions ont longtemps été la plaie des intégrateurs et, pour un outil comme Drupal, leur support représentait un coût assez important alors que le nombre d'utilisateurs concernés ne cessait de baisser. Officiellement, à partir de la 8.4.0, ces versions ne sont donc plus supportées. Cela signifie que les sites continueront de fonctionner comme précédemment mais qu'aucun effort supplémentaire ne sera alloué à cette compatibilité à l'avenir. Les hacks en place pour faire fonctionner certaines choses pour ces versions seront progressivement retirés à partir de Drupal 8.5.

Mise à jour majeure de Symfony et jQuery

Que vous soyez plutôt back ou front, pas de répit avec cette nouvelle version ! Symfony passe à la version 3.2.8+ (au lieu de 2.8+) et jQuery à la version 3.2.1 (au lieu de 2.2.4). Bien que ces deux versions aient une forte compatibilité descendante, si certaines de vos fonctionnalités s'appuient sur des fonctions dépréciées, elles cesseront probablement de fonctionner lors de la mise à jour. Cela a été le cas pour nous sur le menu déroulant d'un projet, par exemple. 

En cas de besoin, vous pouvez consulter le rapport de changement de la mise à jour de Symfony dans le cœur ou le guide de mise à jour de jQuery.

Rupture de compatibilité avec Drush

Du fait des divers changements dans les dépendances et dans la façon dont le cœur gère quelques services, Drush 8.1.14 et inférieur n'est pas compatible avec Drupal 8.4.0 et supérieurs. Si votre Drush est installé localement au projet (il devrait), un simple composer update devrait résoudre le problème. Dans le cas contraire, référez vous à la documentation officielle.

Attention, indépendamment de l'évolution du cœur de Drupal, Drush évolue également vers une nouvelle version majeure, Drush 9. Cette dernière est une réécriture complète de Drush et apporte son lot de nouveautés très intéressantes (on en parlera dans un autre article). Cependant, si vous avez des commandes drush personnalisées, des alias de sites ou des scripts qui utilisent cet outil de façon intensive, prenez votre temps pour monter de version car vous aurez un peu de travail pour adapter votre usage.

Ça bouge chez les expérimentaux !

Si vous avez suivi un peu nos articles concernant les nouveautés de Drupal 8, vous saurez déjà que les versions mineures sont l'occasion d'introduire de nouvelles fonctionnalités sous la forme de modules expérimentaux. Pour la version 8.4, nul nouveau module expérimental mais de nombreux changements.

Les modules Datetime Range, Inline Form Errors, Layout Discovery, Media et Workflows, sont désormais considérés comme stables et plus expérimentaux.

Media, n'est qu'un support pour les modules contribués et ne propose aucune fonctionnalité de lui même. Il est caché dans l'interface de gestion des modules pour éviter les confusions mais sera automatiquement activé en cas de besoin. Si vous utilisiez le module contribué Media Entity avec la précédente version de Drupal, sa version 2.0 contient un chemin de migration obligatoire pour transiter vers le module du cœur.

Workflows, en passant en version stable, a procédé à quelques derniers changements de fond. Selon votre usage du module (surtout si vous l'utilisez autrement qu'avec Content Moderation), vous devriez consulter le rapport de changement associé pour adapter votre code au nouveau fonctionnement. Si vous utilisez Content Moderation, qui a lui aussi subi son lot d'évolutions, vous devriez jeter un œil à son chemin de mise à jour non officiel qui vous permettra de continuer à vous en servir sans altérer vos données.

Migrate, Migrate Drupal et Migrate Drupal UI continuent leur progression vers le support complet d'un chemin de migration de Drupal 6 ou 7 vers Drupal 8. Par exemple, les champs date et node_reference de Drupal 6 pourront désormais être migrés vers Drupal.

Field Layout, dont nous avons détaillé le fonctionnement lors de la précédente mise à jour, a vu quelques corrections de bug mais pas de changement fondamental. Malgré son intérêt fonctionnel, il ne lui reste plus que quelques mois de période probatoire avant d'être éjecté du cœur pour retourner dans le mode des modules contribués.

Settings Tray et Place Blocks continuent leur progression. Le premier s'offre une version beta et pourrait donc accéder à la stabilité à la prochaine version mineure. Le second, lui, va progressivement disparaître pour être absorbé dans le module Block du cœur lors du passage à la 8.5 si tout se déroule comme prévu.

Évolutions de l'interface

Suite à des tests d'utilisabilité auprès d'un large panel d'utilisateurs finaux, il est apparu que le bouton déroulant était trop déroutant. La décision a donc été prise de revenir à un bouton simple doublé d'une case à cocher pour gérer la publication. Dans le cas de l'utilisation du module Workflows, la case à cocher est remplacée par le widget de gestion des états.

Autre amélioration plus mineure : le choix du fuseau horaire dans le compte utilisateur se fait désormais via un menu déroulant groupé par continent et classé par ordre alphabétique (au lieu du classement par décalage horaire qui était utilisé auparavant).

Amélioration des performances

Afin d'adresser des problèmes de tables de cache grossissant jusqu'à atteindre plusieurs Gigas sur certains projets, une option a été ajoutée pour pouvoir poser une limite, par entrepôt de cache, au nombre d'enregistrements pouvant coexister. Cette limite, fixée par défaut à 5000 entrées, peut être ajustée en fonction des besoins du projet très facilement. Par exemple :

$settings['database_cache_max_rows']['bins']['cache_config'] = 500;

De plus, le temps maximal durant lequel un formulaire est conservé dans le cache avant d'avoir été soumis est désormais également configurable. Par défaut, cette durée est de 6 heures mais sur la plupart des sites, une durée bien plus courte est largement suffisante.

Enfin, parmi les autres améliorations, une réécriture du système de gestion des messages de statut permet une économie d'environ 10% de performances sur les pages qui ne contiennent aucun message.

Si vous voulez en savoir plus, vous pouvez lire le résumé complet des modifications apportées par la version 8.4.0 de Drupal sur le site officiel de Drupal.

Photo de couverture © Dominic Alves, retouchée par Happyculture.

Drupal 8.4.0 approche à très grand pas, sa sortie est prévue dans les semaines qui viennent. Vous êtes toujours entrain de travailler sur des projets Drupal 7 et lorgnez sur Drupal 8 ?

Profitez de notre formation pour sauter le pas. Nous organisons une session du 27 au 29 novembre en inter entreprise à Paris.

Vous pourrez apprendre dans cette formation comment fonctionnent sous Drupal 8 vos habitudes et connaissances Drupal 7. Blocs, menus, champs, formateurs, formulaires, modules, outils, industrialisation, cache sont quelques uns des thèmes couverts au cours de ces 3 jours. La liste complète est à découvrir dans le programme détaillé.

Combien coûte cette formation ? De moins en moins selon le nombre de participants ! Le coût est partagé entre chacun. 3 à 6 personnes peuvent participer à chaque session. Le prix global est de 4 500 € HT, ce qui vous donne une formation de 1 500 à 750 € pour trois jours bien remplis d'informations, de réponses à vos questions et de super déjeuners car bien manger est primordial ! (Et puis nous sommes français quand même...).

Je sens que vous ne pouvez plus résister, correct ? Et bien dans ce cas, je vous invite à nous laisser un message pour que l'on vous réserve une place ou lève les doutes / questions que vous pourriez vous poser !

On vous attend !

Je vous partage aujourd’hui une astuce qui peut vous épargner de perdre quelques cheveux. Il s’agit de l’erreur suivante :

The SQL storage cannot change the schema for an existing field (field_meta_keywords in taxonomy_term entity) with data.

Cette erreur survient lorsque vous avez créé un champ et que vous avez configuré ses settings, que cette configuration est passée en production et que vos utilisateurs ont créé du contenu qui remplit les données de ce champ.
Il arrive que vous ayez besoin de modifier la configuration de ce champ. Simple me direz-vous ? Et bien non, pas toujours car Drupal ne va pas vous laisser faire (à raison).

Selon le type de champ que vous modifiez, les settings du champ peuvent être utilisés pour créer les colonnes de la table. Avec du contenu dans la table, hors de question de vous laisser faire n’importe quoi au risque de perdre des données. Drupal va donc lever une exception (FieldStorageDefinitionUpdateForbiddenException) qui est assez explicite, pas de mise à jour du stockage du champ lorsque des données sont présentes.

Comment contourner cela ?

Vous pourriez tenter de modifier directement le fichier .yml de configuration de l’instance du champ à la main mais cela ne contournerait pas votre problème, Drupal comprendrait toujours que vous voulez modifier la configuration et vous protégerait contre la perte de vos données.

La seule solution pour cela est de travailler à un plus bas niveau via un hook_update_N() pour faire le changement de configuration. Il faudra travailler directement sur les fonctions de base de données pour manipuler les colonnes.

Voici donc le code qui permet de faire cela :

/**
 * Changement du schéma de field_meta_keywords stocké dans la configuration.
 */
function project_social_update_8006() {
  // Augmentation de la longueur max du champ de 255 à 500 caractères.
  try {
    // 1. On vide le cache de la définition des champs pour travailler les mains libres.
    \Drupal::service('entity_field.manager')->clearCachedFieldDefinitions();

    // 2. On récupère la définition de notre instance de champ depuis les fichiers de config et on la sauve.
    $storage_definition = \Drupal::service('entity_field.manager')->getFieldStorageDefinitions('taxonomy_term')['field_meta_keywords'];
    \Drupal::service('entity.last_installed_schema.repository')->setLastInstalledFieldStorageDefinition($storage_definition);

    // 3. On récupère la définition du champ.
    $field_schema = \Drupal::keyValue('entity.storage_schema.sql')->get('taxonomy_term.field_schema_data.field_meta_keywords');

    // 4. On définit la nouvelle valeur de notre configuration.
    $field_schema['taxonomy_term__field_meta_keywords']['fields']['field_meta_keywords_value']['length'] = 500;
    // 6. On applique notre nouvelle configuration dans le stockage du champ.
    \Drupal::keyValue('entity.storage_schema.sql')->set('taxonomy_term.field_schema_data.field_meta_keywords', $field_schema);
  }
  catch (SchemaException $e) {
    \Drupal::logger('project_social')->error($e->getMessage());
  }
}

La solution a été réalisée suite à ce patch très inspiré de Berdir qui montre la voie de l'implémentation : https://www.drupal.org/node/2641828#comment-10711058

Bien que l'on ait utilisé les fonctions de bas niveau pour faire les modifications, on aura tout de même exporté la configuration dans son état final pour s'assurer que le la longueur du champ de l'exemple est bien définie à 500 caractères. Cela permet de ne pas détecter de diff une fois notre correctif effectué. (L'export YML et la définition en base doivent être raccords).

Il est à noter évidemment que si vous aviez dû faire des modifications plus compliquée du type supprimer une colonne il aurait fallu des étapes supplémentaires pour ne pas perdre des données. Vous saurez maintenant comment vous y prendre.

Image de couverture par Florent Darrault, via Wikimedia Commons.

Du 21/03/2017 au 25/03/2017 se tiendra la nouvelle édition des Drupal Dev Days à Séville. Si vous nous suivez, vous savez que nous sommes des fidèles de l'événement puisque nous n'en avons raté aucun depuis leur création ! Milan l'année dernière, Montpellier l'année d'avant...

Cette année l'équipe se rendra au sud de l'Espagne pour retrouver la communauté, débattre des sujets du moment et sprinter pendant la semaine. Nous ne serons pas au grand complet malheureusement pour une raison tout à fait valable mais nous serons tout de même bien présents pour vous permettre d'être bien éveillés tout au long de la semaine grâce à notre package de sponsoring café !

Il reste des places pour vous inscrire, vous pouvez également consulter le programme. Si vous n'avez jamais participé à un événement du genre, c'est toujours une parfaite occasion de rejoindre la communauté et de prendre part aux nombreux sprints.

En espérant vous y voir, n'hésitez pas à venir nous dire coucou sur place.