Articles de l'utilisateur

Par Artusamak
Julien Dubois

Interview client - BABYZEN

Interview client - BABYZEN
stephanie@happyculture.coop
ven 26/08/2022 - 16:09

Découvrez comment le site internet de BABYZEN est devenu accessible partout dans le monde avec Happyculture et la mise en place du CMS Drupal. Merci encore à toute l'équipe pour cet entretien et pour ce beau projet !

Logo Babyzen
Corps

Depuis 2007, Babyzen propose des produits de puériculture innovants, durables et pratiques. Yoyo, sa célèbre poussette citadine ultra maniable, en a fait son succès.

Happyculture a été mandaté pour la refonte du site internet. Vous pouvez accéder ici à la présentation du projet et des principales fonctionnalités développées.

1/ Présentation et contexte du projet

Pouvez-vous vous présenter en une phrase (fonction et rôle sur le projet) ainsi que BABYZEN ? 

BABYZEN conçoit, fabrique et distribue les poussettes YOYO dans 85 pays. 
Marina Sokolowsky : "Je suis Brand Communication Manager et j’étais chef de projet sur la construction du site babyzen.com avec Happyculture".
Edouard Villeneuve : "J’ai piloté ce projet d’un point de vue IT en tant que DSI de BABYZEN".

Quelle était votre problématique web qui a nécessité une refonte ?

[Marina Sokolowsky et Edouard Villeneuve] La marque a connu une croissance rapide et notre site web originel ne correspondait plus à nos besoins. Notamment:

  • L’équipe Marketing manquait d’autonomie, et avait besoin de la mise en place d’un vrai CMS,
  • Les performances du site étaient mauvaises, notamment pour nos utilisateurs lointains, ce qui a demandé l’ajout d’un CDN. 

Quels étaient l'objectif et les enjeux de la mission ? 

[Marina Sokolowsky] Le projet concernait la refonte totale de notre site vitrine avec deux enjeux :

  • L’accessibilité partout dans le monde, 
  • 15 langues à mettre en place avec un back office qui permette de les gérer facilement. 

Quelle est la taille de l'équipe qui a suivi la réalisation du projet et le temps que vous y avez consacré ?

[Marina Sokolowsky] Nous étions tous les deux uniquement. La direction était bien sur très impliquée dans le projet dans les arbitrages fonctionnels. 

2/ Collaboration avec Happyculture 

Pourquoi avoir choisi Happyculture ? quels critères de choix ? Comment s’est déroulée la prise de décision ? 

[Edouard Villeneuve] En tant que DSI, j’avais déjà travaillé avec Happyculture (et pas mal d’autres prestataires web) dans ma vie antérieure.
Je connaissais donc Happyculture en tant qu’experts, avec une réputation bien établie pour des assistances ponctuelles. Je les ai contactés pour avoir des recommandations d’agence qui puissent prendre en compte le projet dans son intégralité. 
J’ai alors été surpris de voir qu’Happyculture savait se positionner pas seulement pour des expertises, mais également pour le projet entier de réalisation, avec des taux journaliers très compétitifs, en particulier quand on prend en compte la qualité de la réalisation et donc la productivité et l’absence de dette technique.
J’avais contacté deux autres sociétés qui nous ont moins convaincus, soit à cause de l’approche technique proposée qui était démesurée par rapport à notre typologie, soit à cause de la méthodologie projet pas assez agile et trop commerciale.

Comment s'est passée la collaboration et comment l'agence Happyculture a-t-elle répondu à votre problématique ? 

[Edouard Villeneuve] Une proposition a été rapidement établie par Happyculture, le projet lancé dans la foulée et ensuite une gestion agile des écarts nous a permis d’augmenter le périmètre tout en maitrisant l’impact budgétaire de ces changements. Nous avons ensuite mis en place une TMA pour assurer la maintenance corrective et évolutive. 

Comment se sont organisées la phase de cadrage puis de réalisation du site ? 

[Edouard Villeneuve] Le cadrage était simple puisqu’il s’agissait uniquement de refaire le site à iso-fonctionnalités en termes de périmètre mais simplement avec des nouvelles fonctionnalités côté back office (CMS + CDN). Lorsque nous avons souhaité finalement inclure des évolutions significatives en termes de structure et contenus du site, Happyculture a organisé des ateliers de définition du besoin puis a chiffré ces évolutions individuellement, ce qui nous a permis de maîtriser finement ce changement d’approche.

Comment avez-vous jugé la qualité de ce qui vous a été livré ? A-t-il fallu beaucoup de temps pour trouver les correctifs nécessaires avant mise en ligne ?

[Edouard Villeneuve] Ayant participé à un certain nombre de projets Web en tant que DSI et dans ma vie antérieure, et bien que connaissant la réputation d’Happyculture, j’ai été impressionné par le faible taux de défauts identifiés. Les correctifs ont alors été livrés rapidement, soit par nos interlocuteurs projets, soit par le reste de l’équipe Happyculture lorsqu’un problème a été rencontré en période de congés.

3/ Utilisation de Drupal

Vous n’utilisiez pas Drupal sur votre précédent site. Quels ont été les éléments qui vous ont incité à choisir ce CMS ?

[Edouard Villeneuve] L’utilisation de Drupal dans une expérience professionnelle antérieure mais récente me confortait sur le fait que c’était la bonne plateforme pour répondre à nos enjeux et difficultés. Les éléments particulièrement complexe (type traduction en 15 langues dont certaines lues de droite à gauche) ont été abordées lors de la consultation pour valider ce choix. 

Quel élément vous a le plus été utile dans ce qu'Happyculture a mis en œuvre dans votre projet ? Pourquoi ?

[Marina Sokolowsky et Edouard Villeneuve] Plusieurs éléments utiles ont été mis en oeuvre :

  • Un CDN a été mis en place pour répartir la distribution du site partout dans le monde. La performance du site a été améliorée et le temps de réponse est à peu près identique partout dans le monde,
  • L’édition de contenu par composants permet de constituer des pages du site de manière éditoriale avec plus de liberté tout en respectant la charte et les enjeux marketing de BABYZEN,
  • Le site a été traduit en 15 langues. Cette traduction se fait en autonomie (non statique) et certains contenus ont pu être personnalisés selon le pays. Cette pré-orientation se fait grâce à la détection automatique du pays du visiteur,
  • L’alimentation de la plupart des contenus a été facilitée grâce aux imports,
  • Le Store locator met à disposition l’emplacement des 3 500 revendeurs physiques dans le monde avec recherche par adresse et géolocalisation.

3/ Pour conclure 

Etes-vous globalement satisfaits de ce projet ? Pourquoi ?

[Edouard Villeneuve] Très satisfaits, le sérieux et la disponibilité d’Edouard Cunibil chez Happyculture ont été clés dans le succès du projet. La qualité des développements ont aussi été un critère majeur pour nous assurer de la bonne vie du site et de la capacité d’intégrer des évolutions de manière agile et indolore. Enfin, lorsque plusieurs approches techniques étaient possibles, Edouard a été particulièrement pédagogue pour nos les présenter avec les avantages et inconvénients de chacune, afin de faire un choix éclairé. 

Au terme de plusieurs années d'exploitation de votre site, diriez-vous que vos objectifs ont été atteints ? Comment ?

[Marina Sokolowsky] Nos objectifs ont été atteints. Après 18 mois, ce site inclut 15 langues, ce qui a été fait très facilement et n’avons plus aucun problème d’accessibilité, partout dans le monde.

Recommanderiez-vous Happyculture à un pair et pourquoi ? 

[Marina Sokolowsky] Tout à fait. Le fait d’avoir une seule personne en contact a été précieux tout au long du projet, Edouard connaissait parfaitement nos problématiques et pouvait y apporter des réponses rapides.

 

En savoir plus sur le projet Babyzen ? Accédez ici à la présentation du projet et des principales fonctionnalités développées.

Catégories
Développement
Drupal
Drupal 9
Méthodes agiles
Tags
refonte de site web
CMS
CDN
accessibilité
multilingue
Référence client
Par Artusamak
Julien Dubois

Faut-il remplacer Google Analytics par Matomo ?

Faut-il remplacer Google Analytics par Matomo ?
stephanie@happyculture.coop
jeu 25/08/2022 - 10:51

Matomo, une alternative éthique à Google Analytics, dans le respect des données personnelles et du RGPD.

Corps

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.
 

Tableau de bord de Matomo
Capture d’écran de l’interface du tableau de bord de Matomo des dernières visites au cours du mois écoulé

 

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 :

var _paq = window._paq = window._paq || [];
_paq.push(["setDomains", ["*.monsite.fr"]]);
_paq.push(["setDoNotTrack", true]);
_paq.push(['HeatmapSessionRecording::disable']);
_paq.push(["disableCookies"]);
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
(function() {
var u="https://stats.monsite.fr/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '1']);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
})();

Déclarer une librairie :

matomo:
  js:
    dist/js/matomo.min.js: { minified: true }

Insérer la librairie dans vos pages :

name: Thème de mon site
core_version_requirement: ^8 || ^9
type: theme
# Autres données
libraries:
- mon_theme/matomo

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 ?

Catégories
Drupal
Par Artusamak
Julien Dubois

Évolution ou refonte complète de votre site internet ?

Évolution ou refonte complète de votre site internet ?
stephanie@happyculture.coop
lun 11/04/2022 - 16:06

Pour que votre site internet suive les changements dans les technologies web, les tendances en webdesign et propose la meilleure expérience utilisateur possible, vous pouvez soit le faire évoluer soit procéder à une refonte complète. Décryptons ensemble les solutions.







Corps

Entre l’évolution des technologies web et les tendances du webdesign, votre site internet doit rester à jour et suivre les évolutions techniques.
Une fois mis en ligne, vous l’enrichissez régulièrement de nouveaux contenus. Seulement voilà, au bout de quelques années, votre site peut ne plus correspondre exactement à l’image de votre structure, il vieillit, il peut devenir capricieux techniquement… sachant que l'obsolescence d’un site peut avoir un impact négatif sur votre image de marque et votre activité (design/ergonomie dépassée, baisse des performances économiques, mise à jour du contenu complexe).
Pas mal de raisons qui vous font dire que le changement, c’est maintenant !
Oui mais voilà, qu’est-ce qu’on change ?

Vous avez le choix entre 3 options selon l’étendue des “dégâts” :

  • l’évolution graphique 
  • l’évolution technique
  • la refonte complète

Avant de décider de l’option idéale, vous pouvez étudier les avis clients/prospects qui le visitent, prendre en compte le ressenti des équipes qui utilisent tous les jours le site et lister les problématiques rencontrées, voir ce que font les concurrents etc. Mais surtout vérifiez les statistiques et la performance de votre site. Et demandez-vous aussi ce que vous attendez de lui au regard des objectifs qui l’avaient vu naître.

1/ L’évolution graphique pour une modernisation

Si vous souhaitez remettre au goût du jour la perception visuelle de votre site, vous pouvez faire des petits pas ou décider de totalement repeindre le site.
Si votre site semble daté, vieillot, qu’il ne répond plus aux nouvelles tendances de design, il est temps de lui offrir un lifting. 
Dans une évolution graphique, vous n’allez pas changer la structure, l’architecture générale de votre site. Vous gardez le socle en l’état et modifiez la partie front end ou visible de votre site. 

Actualisez vos images et visuels

N'hésitez pas à remettre au goût du jour vos visuels et à remplacer les images par de nouvelles plus actuelles. Il existe de nombreuses plateformes d’images gratuites et libres de droits. Pensez à garder un œil sur le poids de vos pages pour limiter l’obésité croissante des pages web au fil du temps.

Votre identité visuelle évolue

Si votre identité visuelle évolue, vous allez alors mettre votre site aux couleurs de cette nouvelle charte graphique et intégrer votre nouveau logo, vos boutons et icônes, ou encore la typographie.
Vous pouvez également vouloir simplement moderniser ou rafraîchir la perception du site pour coller à l’air du temps sans tout changer.

Vous réorganisez le contenu

Le design doit être complètement repensé car la circulation dans les contenus n’est pas fluide ou les utilisateurs peinent à trouver ce qu’ils cherchent suite aux conclusions d’un audit en ergonomie par exemple.
Dans ce cas, les travaux seront plus imposants mais vous pourrez capitaliser sur le contenu existant, qui lui reste pertinent. Seule sa présentation et ce qui l’entoure sont retravaillés.

Un site responsive

Aujourd’hui tous les sites internet se doivent d’être responsive, accessible et lisible sur tous les supports, notamment sur les mobiles car 82% des Français se connectent à Internet depuis un mobile. Vous devez adapter votre contenu pour être lisible sur plusieurs largeurs d’écran différentes et optimiser l’espace disponible à l’écran.

2/ L’évolution technique pour augmenter l’impact

Une mise à jour technique peut être nécessaire dans plusieurs cas. 

Optimisez la vitesse de chargement de votre site web

Votre site est-il lent à charger ? Devenue essentiel dans la réussite d’un site internet, la vitesse de chargement a un impact sur la réussite de votre site. Les internautes patientent seulement 3 secondes pour arriver sur votre site. Si dans ce laps de temps, votre site ne s’affiche pas, ils surferont sur des sites concurrents. Travaillez sur le poids des pages, l’utilisation de différents niveaux de cache, le chargement progressif… Faites maigrir votre site.

Il existe des outils pour vérifier la vitesse de chargement de votre site. Notez que la vitesse de chargement sert également votre SEO et votre classement sur Google. 

Migration de votre CMS vers une version plus récente 

Votre CMS a peut-être besoin de passer la vitesse supérieure. On parle ici de montée de version. Jusqu’à novembre 2015, si vous passiez d’une version majeure à une autre de Drupal (exemple de Drupal 7 à Drupal 8), vous étiez obligés de passer par une refonte de votre site pour réappliquer votre code métier et votre contenu à la nouvelle version. Suite aux critiques des agences et autres acteurs de l’écosystème Drupal sur l’importance de l’effort à produire pour y arriver, la communauté a fait évoluer cette logique pour permettre de facilement passer d’une version majeure à une autre (ex : Drupal 8 à Drupal 9). 
Faire une montée de version vous permet de bénéficier des nouvelles fonctionnalités, APIs, optimisations de performances ou refontes d’interfaces.
Le fonctionnement de cette industrie fait que vous devriez toujours chercher à être au plus proche des dernières versions disponibles. 
Si votre site est dit headless, il est possible de modifier le backoffice sans faire évoluer le front-office.
> Notre article sur la fin de vie de Drupal 7 et 8 pourrait aussi vous intéresser.

3/ Repartir d’une feuille blanche

On parle de refonte complète lorsque des modifications en profondeur sont nécessaires et que faire évoluer l’existant sera plus complexe que tout reprendre.

Plusieurs raisons peuvent être à l’origine d’une refonte complète, comme par exemple : 

  • La structure de votre site ne répond pas aux attentes de vos utilisateurs et par conséquent ne répond pas à vos objectifs
  • Votre activité évolue et nécessite le développement de nouvelles fonctionnalités (Le rôle/positionnement du site doit changer suite à des décisions internes)
  • Vous n’avez pas la main sur votre contenu (un prestataire qui vous a enfermé dans un outil propriétaire ) ou 
  • Votre site est difficile à administrer (départ des personnes clés du projet et perte de la compréhension du fonctionnement)
  • Votre DSI vous impose un changement de technologie (changement de CMS ou framework). Changer de CMS implique souvent une refonte car il s'agit d’une migration du back et du front.

Une refonte offre alors plus de possibilités et vous permet d’avoir un site tout neuf et sur-mesure ! 

Mais attention, une refonte ne se fait pas à la légère. Elle doit être bien pensée en amont car elle demande un certain investissement. 

D’abord, c’est un investissement de temps : comptez plusieurs semaines voire plusieurs mois pour un projet de refonte. Ce projet transversal va aussi mobiliser les ressources internes des différents services impliqués dans le site web, ce qui augmentera les chances de réussite de la refonte. Et selon la taille du projet, une personne peut être entièrement dédiée en tant que Chef de projet de la refonte.

Et, c’est aussi un investissement financier : si vous faites appel à une société externe ou un indépendant pour vous aider dans votre chantier de refonte, cela impliquera un budget plus ou moins conséquent selon les travaux que vous souhaiterez leur confier. Selon la maturité de votre projet, une aide externe peut vous aider à capter les besoins de vos utilisateurs ou de votre équipe interne et vous aider dans la rédaction et le cadrage de votre expression des besoins (Happyculture, par exemple !)

Donc avant de vous lancer, vous allez devoir analyser votre site et ses performances, définir vos nouveaux objectifs, lister les problématiques rencontrées, etc, tout ce qui vous servira pour rédiger une bonne expression de besoins avant de contacter l’agence web qui réalisera cette prestation.
On profitera de l’occasion pour s’interroger sur les contenus existants. Faut-il tout conserver ? Tout réécrire ?

Vous devez avoir un cap clair avec vos objectifs de refonte car tout au long de ce projet, ils vous aideront à faire des arbitrages et juger à la fin de la mission si la refonte est une réussite.

Nous serons ravis de répondre à vos questions et de vous accompagner dans votre projet de refonte ou pour vous aider à définir vos objectifs. N’hésitez pas à nous contacter.

=> Et pour allez plus loin, consultez notre guide pour la refonte de votre site (bientôt en ligne).

Enfin, n'hésitez pas à jeter un œil à ce petit musée du web qui montre les changements parfois radicaux de sites web bien connus. 

Pour conclure, la mise en ligne de votre site n’est que le début d’une belle histoire. Pour que votre site reste en phase avec vos objectifs, gardez à l’esprit que la vie d’un site ne s’arrête pas à sa mise en ligne initiale, faites-le évoluer sur la durée et apportez-lui des améliorations régulières. Vous pérenniserez alors les développements effectués, optimiserez les performances de votre site et éviterez une refonte complète à court terme. L’écologie est au centre de bien des préoccupations. Nous devons aussi prendre notre part dans la création de sites. Rallonger la durée de vie des sites doit (re)devenir une préoccupation plutôt que d’entretenir la course au changement permanent. 
 

Crédits : photo de David Zieglgänsberger - Unsplash

Catégories
Développement
Drupal
Tags
refonte
évolution
webdesign
CMS
Par Artusamak
Julien Dubois

Performances des migrations Drupal avec une indexation des contenus pour Search API

Performances des migrations Drupal avec une indexation des contenus pour Search API
DuaelFr
lun 04/04/2022 - 09:00

Les migrations de grandes quantités de contenus dans Drupal et l'indexation dans un moteur de recherche Search API interne ne font pas bon ménage. Individuellement ce sont des opérations efficaces mais conjointement c'est une catastrophe. Que faire ?

Corps

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 ?


Extrait du sketch "Biouman" des Inconnus

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 ?


Bob l'éponge a l'air vraiment perdu. Il s'emmêle les bras en
montrant dans toutes les directions

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 !


Wait… What ?!

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 :

process:
  # ...
  search_api_skip_tracking:
    plugin: default_value
    default_value: 1
  # ...

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) !

Catégories
Développement
Drupal
Drupal 8
Drupal 9
Tags
migration
indexation
search_api
optimisation
Par Artusamak
Julien Dubois

Comprendre les tests automatisés

Comprendre les tests automatisés
DuaelFr
ven 25/02/2022 - 09:19

J'ai récemment eu à accompagner plusieurs équipes sur le sujet des tests automatisés ce qui m'a amené à rechercher des ressources sur Internet pour approfondir les notions que j'avais un peu acquises sur le tas au travers de mes contributions au cœur de Drupal. Le monde des tests est très vaste alors il me semble important d'avoir une bonne culture générale du sujet avant de se lancer étant donné que cela aura un impact sur la conception de votre stratégie de tests.

Vous trouverez donc ci-dessous quelques liens qui vous mèneront vers des articles du plus généraliste au plus spécifique.

Catégories
Par Artusamak
Julien Dubois

Améliorer son référencement pour prendre en charge les types d'entités personnalisés dans Pathauto

Améliorer son référencement pour prendre en charge les types d'entités personnalisés dans Pathauto
Artusamak
lun 21/02/2022 - 08:50

Lorsque vous créez un type d'entité personnalisé, vous voulez bénéficier des fonctionnalités tierces liées aux types de contenu (vues, révisions, traduction...). La génération des alias pour le référencement avec Pathauto est l'un des points incontournables.

Corps

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".

# inspectors/src/Entity/Inspector.php

/**
* Defines the Inspector entity class.
*
* @ContentEntityType(
*   ...
*   links = {
*     "add-form" = "/admin/content/inspector/add/{inspector}",
*     "add-page" = "/admin/content/inspector/add",
*     "canonical" = "/inspector/{inspector}",
*     "edit-form" = "/admin/content/inspector/{inspector}/edit",
*     "delete-form" = "/admin/content/inspector/{inspector}/delete",
*     "collection" = "/admin/content/inspector"
*   },
*   ...
* )
*/
class Inspector extends RevisionableContentEntityBase {}

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.

# inspectors/src/Plugin/pathauto/AliasType/InspectorsAliasType.php

/**
* Defines the Inspector entity class.
*
* @AliasType(
*   id = "inspector_aliases",
*   label = @Translation("Inspectors"),
*   types = {"inspector"},
*   context_definitions = {
*     "inspector" = @ContextDefinition("entity:inspector")
*   }
* )
*/
class InspectorsAliasType extends EntityAliasTypeBase {}

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 :

# inspectors.module

/**
* Implements hook_ENTITY_TYPE_update().
*/
function inspectors_inspector_update(Drupal\Core\Entity\EntityInterface $entity) {
  $generator = \Drupal::service('pathauto.generator');
  try {
    $generator->createEntityAlias($entity, 'update');
  }
  catch (\InvalidArgumentException $e) {
    $generator->messenger()->addError($e->getMessage());
  }
}

/**
* Implements hook_ENTITY_TYPE_insert().
*/
function inspectors_inspector_insert(Drupal\Core\Entity\EntityInterface $entity) {
  $generator = \Drupal::service('pathauto.generator');
  try {
    $generator->createEntityAlias($entity, 'insert');
  }
  catch (\InvalidArgumentException $e) {
    $generator->messenger()->addError($e->getMessage());
  }
}

/**
* Implements hook_ENTITY_TYPE_delete().
*/
function inspectors_inspector_delete(EntityInterface $entity) {
  \Drupal::service('pathauto.alias_storage_helper')->deleteEntityPathAll($entity);
}

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.

# inspectors/src/Plugin/pathauto/AliasType/InspectorsAliasType.php

class InspectorsAliasType extends EntityAliasTypeBase {

  /**
   * Update the URL aliases for multiple entities.
   *
   * @param array $ids
   *   An array of entity IDs.
   * @param array $options
   *   An optional array of additional options.
   *
   * @return int
   *   The number of updated URL aliases.
   */
  protected function bulkUpdate(array $ids, array $options = []) {
    $options += ['message' => FALSE];
    $updates = 0;
    $generator = \Drupal::service('pathauto.generator');

    $entities = $this->entityTypeManager->getStorage($this->getEntityTypeId())->loadMultiple($ids);
    foreach ($entities as $entity) {
      // Update aliases for the entity's default language and its translations.
      foreach ($entity->getTranslationLanguages() as $langcode => $language) {
        $translated_entity = $entity->getTranslation($langcode);

        try {
          $result = $generator->createEntityAlias($translated_entity, 'update');
        }
        catch (\InvalidArgumentException $e) {
          $generator->messenger()->addError($e->getMessage());
        }

        if ($result) {
          $updates++;
        }
      }
    }

    if (!empty($options['message'])) {
      $this->messenger->addMessage($this->translationManager
        ->formatPlural(count($ids), 'Updated 1 %label URL alias.', 'Updated @count %label URL aliases.'), [
        '%label' => $this->getLabel(),
      ]);
    }

    return $updates;
  }

}

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.

Catégories
Développement
Drupal
Drupal 8
Drupal 9
Tags
pathauto
type d'entité
seo
alias
Par Artusamak
Julien Dubois

11 raisons de choisir Drupal pour votre site web

11 raisons de choisir Drupal pour votre site web
stephanie@happyculture.coop
lun 06/12/2021 - 10:25

Drupal s’est imposé comme une référence parmi les meilleures solutions pour la réalisation de sites web. Il fait partie du top 6 des systèmes de gestion de contenu. C’est une solution robuste, flexible et fiable, qui sait s’adapter aux évolutions et aux attentes des utilisateurs.







Corps

Drupal est un CMS, ou SGC en français, libre et ouvert, écrit en PHP en 2001.
Conçu pour couvrir un large éventail de types de sites, il s’est imposé comme l’un des acteurs majeurs de la sphère web.

Il existe plusieurs options pour créer des sites web, mais chez Happyculture, nous les concevons avec Drupal depuis presque 15 ans. C’est pour nous l’outil idéal pour réaliser votre site internet de contenu et pour vous convaincre, nous vous avons listé les 11 principales raisons. 

1/ Compatibilité

Site internet, intranet ou encore extranet, site vitrine ou e-commerce, de quelques pages à des millions de contenus, multilingue… Drupal est conçu pour couvrir un large éventail de types de sites, du plus simple au plus complexe grâce à son évolutivité. Il saura s’adapter aux besoins de votre infrastructure pour encaisser des pics de trafic réguliers ou un grand volume de visiteurs.

2/ Simplicité d’utilisation

D’une manière générale, la gestion de contenu est un point fort de Drupal. Ainsi, Drupal permet de créer facilement des contenus et de les afficher sous forme de listes, de messages, de galeries, de tableaux, de cartes ou de blocs : il suffit simplement de remplir des champs qui constituent des types de contenu. Et pour vos textes riches, il vous facilite la saisie via l’éditeur WYSIWYG CKEditor 4 (et bientôt 5 !). 

3/ Modularité

Drupal est riche d'un écosystème bien vivant depuis 2001 qui lui permet de compléter les fonctionnalités variées et proposées par le cœur de Drupal. De cette force est né l'adage "il y a un module pour ça", décrivant la profondeur du catalogue de modules gratuits à disposition.
Tous les 6 mois, Drupal publie également une mise à jour avec de nouvelles fonctionnalités afin de rester en phase avec son marché et la demande des utilisateurs.

4/ Des technologies dans l’air du temps

Thèmes compatibles avec le “responsive design” et le “mobile friendly”, utilisation du HTML5, intégration avec des webservices, meilleur respect des standards : Drupal s’appuie sur les pratiques du web moderne, favorisant le référencement naturel et l’accessibilité.

5/ Pérennité

Choisir Drupal, c’est faire le choix de l’open source pour ne pas être lié à une solution CMS propriétaire empêchant les évolutions de prestataire et le contrôle des coûts. C’est un outil gratuit et ouvert.
Dès sa création, la communauté mondiale de Drupal n'a eu de cesse de trouver des solutions pour s'assurer que Drupal soit un outil pérenne et ne se laisse pas dépasser par le dynamisme du marché. Publication de correctifs de sécurité réguliers, maintenance mensuelle, conférences pluriannuelles internationales et nationales permettent à la communauté de faire vivre la solution.

6/ Communautaire

Drupal s’appuie sur un réseau mondial de plus d’1 million d’utilisateurs dont 31 000 développeurs dans plus de 230 pays et plus de 3 000 contributeurs à son cœur. C’est l'un des plus gros projets open source au monde.
Happyculture fait d’ailleurs partie de ces contributeurs et reverse régulièrement du code depuis plusieurs années. Happyculture contribue à l’organisation de la communauté en étant impliquée dans les événements nationaux, en proposant des conférences ou en animant des ateliers. Ce qui fait  de nous l’une des 70 sociétés les plus prolifiques au monde par leur contribution au cœur de Drupal.

7/ SEO optimisé

On ne peut pas parler site web sans aborder la question du SEO. Votre site a besoin d’un minimum de visibilité. Drupal propose alors une suite d’outils SEO pour optimiser le référencement naturel de votre site et améliorer son positionnement dans les résultats des moteurs de recherche.

8/ Accessibilité

Drupal propose clé en main une solution compatible avec les exigences WCAG 2.0 équivalentes au niveau bronze/A du RGAA 3.0 et ambitionne d’atteindre le niveau argent/AA.
C’est un des seuls outils à proposer un tel niveau d’exigence clé en main. Il reste de votre responsabilité de maintenir ce niveau d’accessibilité lors de la rédaction de vos contenus ou la création de votre identité graphique pour ne pas perdre en qualité.
Nous vous renvoyons vers notre article dédié à l’accessibilité pour (re)découvrir quelques points de vigilance et conseils de mise en œuvre.

9/ Sécurité

La communauté Drupal assure le suivi des failles de sécurité, la publication de correctifs et la mise à disposition des utilisateurs d’informations pour assurer la sécurité de leurs sites web contre les attaques. 
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.
Autant dire que Drupal est bien sécurisé !

10/ Réversibilité 

L’une des raisons intéressantes qui jouent en faveur de Drupal est la facilité à trouver un autre prestataire pour reprendre un projet en cours, c’est le principe de réversibilité. Vous pouvez récupérer l’intégralité de la base de code et de la base de données, les installer très simplement chez un autre prestataire et continuer à faire vivre votre site. Mais cela peut dépendre de votre contrat avec votre prestataire, pensez à vérifier !

11/ Une référence dans le monde

Drupal est une solution qui dispose notamment d’une belle notoriété dans les secteurs de l’éducation et de la recherche, mais également dans la santé, auprès de gouvernements ou encore de structures de l’ESS. 

En France :

Dans le monde :

Et bien d’autres encore :

Drupal est aujourd’hui l’un des meilleurs systèmes de gestion de contenu et nous espérons que les raisons citées vous ont convaincu ou donné envie d’en savoir plus. 
Alors, si vous souhaitez lancer un projet ou avez des questions sur l’utilisation de Drupal, n'hésitez pas à nous contacter.
 

Catégories
Développement
Drupal
Drupal 10
Drupal 9
Tags
Drupal
CMS
accessibilité
seo
Par Artusamak
Julien Dubois

Pourquoi encore choisir un CMS pour son site web en 2022 ?

Pourquoi encore choisir un CMS pour son site web en 2022 ?
stephanie@happyculture.coop
mar 02/11/2021 - 09:44

Au fil du temps, la production de sites internet s’industrialise. Le coût d’entrée d’un site s’est considérablement abaissé et plusieurs options s’offrent à vous lorsque vous devez lancer un nouveau site. Explorons-les ensemble.







illustration des différentes fonctionnalités d'un CMS
Corps

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.

  Option 1 :
Site SaaS

Option 2 :
Site CMS

Option 3 :
Site Framework
Coût de la conception et du développement + +++ ++++
Adaptabilité aux besoins métiers Impossible ++ +++
Personnalisation à votre image de marque + +++ +++
Connaissances techniques requises + +++ +++
Réversibilité Impossible Possible Possible
Coût récurrent tout au long de la vie du site :
Licence / Abonnement ++ Gratuit (open source)
 / 
+ (propriétaire)
Gratuit
Hébergement Compris ++ ++
Maintenance Compris ++ ++

 

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.

Catégories
Développement
Drupal
Drupal 9
Par Artusamak
Julien Dubois

Mettre à jour vers Drupal 9 à l'aide de Lenient

Mettre à jour vers Drupal 9 à l'aide de Lenient
DuaelFr
lun 11/10/2021 - 09:00

À ce jour il reste un peu plus de 3000 modules qui n'ont pas encore été mis à jour de Drupal 8 vers Drupal 9. Découvrez dans cet article comment contourner ce problème pour monter la version de votre site.







Corps

Comme nous l'indiquions dans un précédent article, Drupal 8 cessera d'être supporté le 2 novembre 2021 soit, à l'heure où cet article est écrit, dans moins d'un mois. Or, même si les mises à jour majeures ont été largement simplifiées depuis la sortie de Drupal 8, le fait d'avoir plusieurs modules en retard peut être complexe à gérer pour passer à cette nouvelle version majeure. En effet, chaque module (ou thème) déclare la ou les versions avec lesquelles il est compatible et si la personne qui le maintient n'est plus très réactive cela peut retarder votre propre montée de version.

Fonctionnement concret du système de gestion des dépendances

Concrètement, à partir du fichier info.yml des modules, le serveur packagist de Drupal va générer un arbre de dépendances. Lorsque votre composer va réclamer une mise à jour, cet arbre de dépendances sera analysé pour vérifier que tous vos paquets (core, modules, thèmes, etc.) sont compatibles entre eux. Un module qui ne déclarera donc pas officiellement supporter Drupal 9 ne sera pas reconnu comme compatible avec une montée de version du cœur et bloquera donc la procédure.

La mise à jour de Drupal 8 vers Drupal 9 étant principalement liée au remplacement de code déprécié et à la déclaration effective du support de la nouvelle version, la communauté a mis en place il y a plusieurs mois un robot qui est passé sur tous les modules ayant une version compatible avec Drupal 8 pour y indiquer les problématiques à traiter et proposer un patch lorsque c'était possible. Cependant, tant que ce patch n'est pas intégré par les personnes en charge de la maintenance des modules, le système de gestion des dépendances ne peut pas mettre à jour son arbre. En effet, même si vous appliquez le patch localement, cela intervient après le calcul des dépendances et ne permet donc pas de contourner le problème.

Initiative d'accélération des mises à jour

Face à l'approche de la fin de vie de Drupal 8, la communauté propose deux pistes pour aider la transition à se faire.

Ouverture à l'adoption des modules

Tous les modules et thèmes ayant une version de Drupal 8 mais pas de Drupal 9 ont été ouverts à l'adoption. Au terme d'une période de deux semaines durant laquelle les personnes en charge de la maintenance peuvent choisir de refuser de céder leur place (et potentiellement faire le nécessaire pour corriger le problème de compatibilité), il est possible pour quiconque dans la communauté de demander à se faire transférer la charge pour prendre la suite et rendre le module ou le thème compatible.

Création du point d'entrée composer Lenient

Auparavant, la méthode recommandée pour contourner le problème de gestion des dépendances de composer était de déclarer manuellement, pour chaque module ou thème impliqué, un repository personnalisé pour aller récupérer le code directement via git au lieu de passer par le packagist de Drupal. C'était un processus fonctionnel mais très fastidieux. La communauté, à l'écoute de tous les gestionnaires de sites en détresse, a donc mis en place un nouveau service appelé Lenient. C'est un nouveau dépôt packagist qui ne contient que les modules n'ayant pas encore de compatibilité Drupal 9 et qui ne déclare pas de dépendance sur le cœur de Drupal. Il vous permet ainsi de monter votre version du cœur sans blocage et d'appliquer ensuite les patchs qui permettront au module de fonctionner effectivement. Dès que le module aura été repris en main et que sa compatibilité aura été officialisée, il sera automatiquement retiré de Lenient et repassera pas le système original.

Utiliser Lenient pour votre mise à jour

Pour exploiter le potentiel de ce nouveau point d'entrée, vous devez utiliser composer 2 et mettre à jour votre composer.json en y ajoutant le nouveau repository avant le gestionnaire habituel de drupal.org.

Par exemple, si votre composer.json ressemble à ça (si vous vous demandez ce qu'est ce repository "assets" je vous invite à lire notre article sur la gestion des librairies front via composer) :

    "repositories": {
        "assets": {
            "type": "composer",
            "url": "https://asset-packagist.org"
        },
        "drupal": {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    }

Il faut le transformer pour qu'il ressemble à ça :

    "repositories": {
        "assets": {
            "type": "composer",
            "url": "https://asset-packagist.org"
        },
        "lenient": {
            "type": "composer",
            "url": "https://packages.drupal.org/lenient"
        },
        "drupal": {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    }

Ce nouveau repository prendra la priorité sur l'ancien pour tous les modules et thèmes n'étant pas encore officiellement portés et retirera leur dépendance au cœur (et uniquement au cœur) pour débloquer votre processus de mise à jour via composer. Cependant, pour que votre dépendance puisse être utilisée dans Drupal il est nécessaire que les changements soient appliqués au code. Bien heureusement il est aussi possible de le faire via composer et ce relativement facilement ! Je vous invite à consulter cet article d'un de nos confrères de la communauté Drupal française qui vous expliquera comment utiliser composer pour appliquer un ou plusieurs patchs sur vos dépendances.

Catégories
Drupal
Drupal 8
Drupal 9
Tags
composer
upgrade
Par Artusamak
Julien Dubois

Charger vos librairies front via composer

Charger vos librairies front via composer
DuaelFr
lun 04/10/2021 - 15:00

De nombreux modules requièrent des librairies front externes pour fonctionner correctement. Plutôt que les charger manuellement, cet article explique comment les gérer via composer.







Corps

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 :

    "repositories": {
        "drupal": {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        "assets": {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    },

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.
    "extra": {
        "installer-types": ["bower-asset", "npm-asset"],
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": [
                "type:drupal-library",
                "type:bower-asset",
                "type:npm-asset"
            ],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/Commands/contrib/{$name}": ["type:drupal-drush"],
            "web/modules/custom/{$name}": ["type:drupal-custom-module"],
            "web/themes/custom/{$name}": ["type:drupal-custom-theme"]
        },
    }

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 !

Catégories
Drupal
Drupal 10
Drupal 8
Drupal 9
Tags
composer
libraries
Par Artusamak
Julien Dubois

Avez-vous anticipé la fin de vie de Drupal 7 et 8 ?

Avez-vous anticipé la fin de vie de Drupal 7 et 8 ?
stephanie@happyculture.coop
lun 02/08/2021 - 17:24

Alors que Drupal 8 cèdera sa place à Drupal 9 cette année, Drupal 7 quant à lui reste en sursis jusqu’en novembre 2022.
Alors n’attendez plus, passez à Drupal 9 !




Migrer de Drupal 7 ou 8 à Drupal 9
Corps

Que se passe-t-il ?

Dès 2019, la date de fin de vie de Drupal 7 et Drupal 8 a été annoncée. Ce sera pour le mois de novembre 2021.

La règle dans la communauté Drupal c’est 2 versions majeures maintenues en simultané (Drupal 7 et Drupal 8 à l’époque). L’arrivée de Drupal 9 devait pousser Drupal 7 vers la retraite mais papy fait de la résistance !

En effet, son utilisation importante chez de nombreux utilisateurs finaux, la migration complexe vers Drupal 8 et le COVID ont repoussé son arrêt de carrière de 12 mois, il jouera donc les prolongations jusqu’en novembre 2022

De son côté, Drupal 8 est toujours rangé au placard à la date prévue car c’est sa dépendance à Symfony 3 qui arrive en fin de vie et qui lui fera quitter les projecteurs en novembre 2021.


Drupal release cycle
@hugovk

 

Quels sont les risques ?

Avec le retrait de ces deux versions, votre système de gestion de contenu ne va pas arrêter de fonctionner du jour au lendemain.

Ce que signifie leur fin de vie c’est que les équipes officielles qui s’occupent de maintenir le logiciel ne le feront plus. Il n’y aura donc plus de mises à jour de correctif ou de sécurité. Votre site ne bénéficiera plus de la protection offerte par l’équipe de sécurité de drupal.org. Elle s’assure que tous les modules, thèmes, distributions et le cœur de Drupal sont sécurisés. Qu’aucune faille ne peut être exploitée par des pirates et le cas échéant, produit des patchs de sécurité pour que vous puissiez mettre à jour vos sites en toute sérénité. C’est cette partie là qui s’arrête au mois de novembre 2021 pour Drupal 8.

 

Que dois-je faire ?

Selon vos sites, vous êtes dans l’une des deux situations suivantes :

Mon site est sous Drupal 7

D’ici au mois de novembre 2022, vous devez lancer le chantier de montée de version de votre site. Vers Drupal 9 ou vers un autre CMS, vous devez vous posez la question de l’impact de cette échéance.
À l’instar de Drupal 6, quelques grosses sociétés expertes Drupal ont annoncé qu’elles contribueraient à la maintenance de correctifs de sécurité de Drupal 7. Si une faille de sécurité importante venait à être découverte, ils s’engagent à reverser à la communauté le patch de sécurité aussitôt qu’il sera disponible.
Bien que cela soit une bonne nouvelle, ils ne maintiendront pas tout l’écosystème des modules utilisés par Drupal 7. Vous devez tenir compte de cette échéance pour gérer la montée de version de votre site.

Si votre site n’est plus dynamique, vous pouvez envisager une statification pour ne pas vous engager dans une refonte.

Il vous reste 16 mois pour agir, la durée moyenne d’un projet de refonte est de plusieurs mois. Ne traînez pas, nous pouvons vous aider !

Mon site est sous Drupal 8

Si votre site est sous Drupal 8, l’échéance est dans 4 mois mais, la bonne nouvelle c’est que la route est bien plus droite. En effet, le principal reproche fait à Drupal 6 et 7 était la complexité des montées de versions majeures. Comme nous l’avons indiqué précédemment, passer de Drupal 7 à Drupal 9 est un coût non négligeable. Ce frein a été entendu par la communauté et la gestion des montées de version a été revue pour en tenir compte. Depuis Drupal 8, la montée de version est sans friction car pour peu que vous mainteniez votre site Drupal 8 à jour, le passage à Drupal 9 consiste à simplement retirer le code déprécié entre les deux versions. Ce qui est une quantité bien moindre que précédemment.

Le coût de la montée de version est donc quasiment le même que celui d’une montée intermédiaire. On parle de quelques jours tout au plus contre des semaines voire des mois précédemment (car on en profitait en général pour changer bien d’autres choses par la même occasion).

Votre équipe technique devra donc s’occuper de cela et ne devrait pas avoir de problèmes pour gérer cette montée de version. Les quelques freins qui peuvent exister étant des modules contribués non compatibles avec Drupal 9 mais ils sont minoritaires. 100% du top 200 des modules et 95% du top 1000 est compatible avec Drupal 9.

Vous souhaitez en savoir plus ? Vous souhaitez migrer votre site vers Drupal 9 ?
Contactez-nous !

Catégories
Drupal
Drupal 7
Drupal 8
Drupal 9
Tags
Drupal
Par Artusamak
Julien Dubois

Remplacer son code jQuery par du code natif "vanilla"

Remplacer son code jQuery par du code natif "vanilla"
Artusamak
jeu 08/04/2021 - 09:42

Drupal 9 a initié une tendance de fond depuis plusieurs années au sein de sa base de code qui consiste à retirer sa dépendance à jQuery afin d'alléger le poids des pages (en l'invoquant à la carte) puis en le remplaçant par des implémentations dites vanilla (en javascript natif pur).

Cette tendance de fond est possible car les navigateurs ont bien progressé et leurs implémentations sont uniformisées, au point que les années de jQuery soient comptées (pas seulement à cause de cela).

Par réflexe ou par habitude, beaucoup de développeurs (back) savent développer certains comportements interactifs avec jQuery mais ne savent pas le faire de façon vanilla. Ces liens recensent quelques techniques et snippets d'équivalence pour les taches les plus courantes.

 

Catégories
Auteur
Par Artusamak
Julien Dubois

Drupalcamp Paris 2019 - Bilan des trois jours

Drupalcamp Paris 2019 - Bilan des trois jours
Artusamak
mar 05/03/2019 - 08:55

Retrouvez le lien vers la présentation RGPD donnée par Guillaume et le compte-rendu de nos efforts de sprint de traduction.

Corps

Nous voilà enfin remis de la traditionnelle Drupal flu, il est temps de vous partager le bilan de ces 3 jours de Drupalcamp Paris 2019.

Un camp, c'est surtout l'occasion de retrouver les copains et les copines de la communauté, mais aussi de faire de nouvelles rencontres ! On aurait aimé qu'Edouard puisse être parmi nous mais une contrainte de dernière minute l'a forcé à nous abandonner.

L'innovation de cette édition résidait dans la tenue d'une session Business où les clients ont pu enchaîner les retours d'expérience sur la mise en œuvre de leurs projets. Nous avons convié l'UNESCO à venir témoigner sur ses problématiques de gestion de multi-sites après plusieurs années et comment nous les accompagnons pour les aider à optimiser leur temps.

L'après-midi, Guillaume a fait une présentation sur le choix de modules pour mettre en œuvre les recommandations du RGPD avec Drupal dans la session Experts. Vous saurez quel module utiliser dans quelle situation avec ses slides.

Le lendemain, j'ai répondu à l'invitation pour répondre à la question "Pourquoi choisir Drupal" où les anciens présidents de l'association ont pu défendre Drupal :

Et pour terminer, le dimanche a eu lieu la journée de sprints. Là on peut dire que l'on a explosé les compteurs, l'équipe de traduction était remontée pour avoir le cœur à nouveau à 100% de chaînes traduites et validées. Il en manquait environ 260 au début du camp, le nombre est tombé à 0 et même mieux, les modules Pathauto, Metatag, Redirect, Recaptcha, Honeypot, Inline Entity Form, Diff, Paragraphs et Fences sont passés à 100% de chaînes avec suggestions ! Il ne reste plus qu'à les valider dans les semaines qui viennent pour concrétiser ces efforts. Le guide utilisateur français a même vu sa traduction se remettre en marche.

Merci et bravo à tous les contributeurs et toutes les contributrices qui ont beaucoup donné pour ce sprint. Tous les progrès sont visibles ici : https://mensuel.framapad.org/p/dcp2019-sprints

Rendez-vous au prochain camp pour de nouveaux progrès ! Merci aux volontaires qui ont aidé à l'organisation, on sait que vous y avez laissé beaucoup d'énergie. Mention particulière pour la nourriture, vous avez fait l'effort de proposer des menus végétariens pour tous, c'était une super idée responsable. On valide !

Catégories
Drupal
Tags
session
contribution
Par Artusamak
Julien Dubois

Drupalcamp Paris 2019 - Venez nous retrouver

Drupalcamp Paris 2019 - Venez nous retrouver
Artusamak
ven 08/02/2019 - 11:01

Retrouvez les experts Drupal d'Happyculture au Drupalcamp Paris 2019.

Corps

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

Catégories
Drupal
Tags
rgpd
retour d'expérience
Par Artusamak
Julien Dubois

Créer un système d'annonces simple avec Drupal 8 (seconde partie)

Créer un système d'annonces simple avec Drupal 8 (seconde partie)
DuaelFr
mar 04/12/2018 - 09:30

La première partie de cet article décrivait l'analyse et l'implémentation du système d'annonce présent sur notre site. Dans cette partie nous aborderons l'affichage de l'annonce et la gestion du cache.

Corps

Dans la première partie de cet article, nous avons créé un formulaire qui nous permet de configurer une annonce, sa date de début, sa date de fin et son contenu. Désormais, il nous faut afficher ces informations en respectant la configuration, notamment les dates.

Pour afficher des informations dans une zone définie d'un site Drupal, en dehors de la zone de contenu, nous avons un mécanisme tout désigné : les blocs. Selon la demande initiale, nous devons donc créer un bloc qui sera présent sur toutes les pages du site, lorsque l'annonce est activée et que nous sommes entre la date de début et la date de fin de l'annonce.

Création du bloc

Nous l'avons déjà couvert dans les billets issus de notre formation, la création d'un bloc passe par la création d'un Plugin, soit la forme d'une classe PHP munie d'une Annotation. Dans notre cas, comme pour le formulaire de paramétrage, nous aurons besoin de pouvoir accéder aux données stockées dans la State API et nous aurons donc une dépendance à injecter. La différence principale est que la classe BlockBase n'implémente pas déjà l'interface nécessaire et qu'il faudra donc le faire nous même. Vous le constaterez, du fait que nous manipulions un Plugin et plus juste un formulaire, les méthodes create() et __construct() auront besoin de quelques paramètres complémentaires. Voyons voir ce que l'on doit mettre dans notre fichier src/Plugin/Block/Announcement.php.

namespace Drupal\hc_announce\Plugin\Block;

use Drupal\Core\Block\BlockBase;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\Core\State\StateInterface;

/**
* Provides a 'Announcement' block.
*
* @Block(
*  id = "announcement",
*  admin_label = @Translation("Announcement"),
* )
*/
class Announcement extends BlockBase implements ContainerFactoryPluginInterface {

  /**
   * @var array
   */
  protected $config;

  /**
   * Constructs a new Announcement object.
   *
   * @param array $configuration
   *   A configuration array containing information about the plugin instance.
   * @param string $plugin_id
   *   The plugin_id for the plugin instance.
   * @param string $plugin_definition
   *   The plugin implementation definition.
   * @param \Drupal\Core\State\StateInterface $state
   */
  public function __construct(
    array $configuration,
    $plugin_id,
    $plugin_definition,
    StateInterface $state
  ) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
    $this->config = $state->get('hc_announcement');
  }

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

  /**
   * {@inheritdoc}
   */
  public function build() {
    return ['#markup' => 'Content of the block'];
  }

}

Bien, maintenant que le bloc est créé et après une petite vidange du cache, vous devriez le voir apparaître dans la liste des blocs disponibles dans l'administration du site. Une fois positionné dans la région de notre choix, on a bien la chaîne "Content of the block" qui apparaît sur le site. Tâchons de faire un petit peu mieux en affichant au moins le contenu stocké dans le State pour que les personnes en charge de l'intégration puissent commencer à travailler sur l'aspect visuel. Nous enrichissons donc la méthode build() de notre bloc comme suit.

  /**
   * {@inheritdoc}
   */
  public function build() {
    $build = [];

    $build['#title'] = $this->config['title'];
    $build['#attributes'] = [
      'class' => ['announcement'],
    ];

    $build['announcement'] = [
      '#type' => 'container',
      '#attributes' => ['class' => ['announcement__content']],
      'content' => [
        '#type' => 'processed_text',
        '#text' => $this->config['announcement']['value'],
        '#format' => $this->config['announcement']['format'],
      ],
    ];

    return $build;
  }

Cela fonctionne bien. Cependant, nous ne respectons pas l'état d'activation de l'annonce ni ses dates de début et de fin. Pour l'état de l'annonce rien de plus simple. Avec un test dans la méthode build(), il est toujours possible de renvoyer un tableau vide si l'annonce est inactive. Pour manipuler les dates, nous avons par contre besoin d'une nouvelle dépendance sur le service datetime.time du cœur. Nous ajoutons donc ce service à la méthode create(), à la méthode __construct() et l'enregistrons dans un attribut $time au niveau de l'objet. Puis, nous ajoutons le code suivant à la méthode build() pour renvoyer un bloc vide si le bloc n'est pas supposé être actif.

    if (empty($this->config['enabled'])) {
      return $build;
    }

    $now = $this->time->getRequestTime();
    $start = (new \DateTime($this->config['start_date'] . ' 00:00:00'))->getTimestamp();
    $end = (new \DateTime($this->config['end_date'] . ' 23:59:59'))->getTimestamp();
    if ($now < $start || $now > $end) {
      return $build;
    }

Trop facile ? Vous n'avez pas tort...

Le problème du cache

Comme indiqué en introduction de cet article, ce bloc va être visible sur toutes les pages du site. Il est donc particulièrement important de bien gérer son cache car sinon nous pouvons être confrontés à deux problématiques majeures :

  1. le bloc est affiché quand il est supposé être inactif ou ne s'affiche pas quand il est supposé être actif,
  2. aucune des pages du site n'est mise en cache.

Nous avions déjà abordé le sujet du cache dans Drupal 8 dans un précédent article sans toutefois aborder le cas un peu spécifique des blocs. En effet, ces derniers utilisent les mêmes métadonnées que les render arrays abordés dans l'article mais définies par des méthodes spécifiques : getCacheContexts(), getCacheMaxAge() et getCacheTags(). Ces dernières vont permettre d'indiquer au service BlockManager, comment mettre en cache le bloc dans son intégralité. Lors du rendu d'une page, si le BlockManager se voit demander un bloc qu'il considère comme ayant un cache valide, il va le renvoyer sans même tenter d'instancier sa classe ou d'appeler sa méthode build() ! Par défaut, tous les blocs sont mis en cache de façon permanente et sans aucune variante. Comme pour le reste des métadonnées de cache, ces dernières se propagent vers le conteneur. Il n'est donc pas souhaitable de se faciliter la vie en désactivant totalement le cache de notre bloc sinon cela signifierait désactiver le cache de toutes les pages du site (en vrai c'est mieux fait que ça, mais on simplifie un peu pour avancer).

Gérer la temporalité du cache

Dans notre cas bien particulier, nous allons devoir prévoir trois cas distincts :

  1. si la date de début n'est pas encore arrivée nous devons mettre en cache jusqu'à cette date,
  2. si la date de début est passée mais la date de fin pas encore, nous devons mettre en cache jusqu'à la date de fin,
  3. si la date de début et de fin sont passées ou si l'annonce est désactivée, nous devons mettre en cache de façon permanente.

Pour atteindre ce but, nous allons simplement implémenter la méthode getCacheMaxAge() de la façon suivante :

  /**
   * {@inheritdoc}
   */
  public function getCacheMaxAge() {
    $max_age = parent::getCacheMaxAge();
    if (!empty($this->config['enabled'])) {
      $now = $this->time->getRequestTime();
      $start = (new \DateTime($this->config['start_date'] . ' 00:00:00'))->getTimestamp();
      $end = (new \DateTime($this->config['end_date'] . ' 23:59:59'))->getTimestamp();

      if ($now < $start) {
        $max_age = Cache::mergeMaxAges($max_age, $start - $now);
      }
      elseif ($now < $end) {
        $max_age = Cache::mergeMaxAges($max_age, $end - $now);
      }
    }

    return $max_age;
  }

Notez l'usage de la méthode \Drupal\Core\Cache\Cache::mergeMaxAges() qui permet de proprement fusionner le max-age par défaut avec la valeur que l'on souhaite configurer. Dans notre cas, cela n'aurait rien changé de renvoyer directement la valeur calculée mais c'est une bonne habitude à prendre d'utiliser les méthodes de fusion des métadonnées de cache pour éviter les mauvaises surprises. La méthode mergeMaxAges() s'assure que l'on conserve toujours le max-age le plus contraignant (et c'est exactement pour cette raison que si on désactive le cache d'un bloc, toute la page est impactée).

Gérer les changements de configuration

Maintenance que la temporalité de notre cache est bien établie, il nous faut prendre en compte les changements qui pourraient venir de l'action d'une personne dans l'interface d'administration. En effet, si le titre ou une date change, par exemple, le cache du bloc devrait immédiatement être invalidé pour prendre en compte les nouvelles données. Dans le cas contraire, les gestionnaires du site n'auraient pas d'autre option que d'invalider la totalité du cache du site. Le mécanisme qui permet cette invalidation, ce sont les cache tags. La plupart des objets gérés par le cœur comme les entités de contenu ou de configuration disposent de cache tags pour les identifier mais ce n'est malheureusement pas le cas de la State API. Fort heureusement, c'est un problème très simple à contourner.

Tout d'abord, définissons un cache tag personnalisé et rattachons le à notre bloc grâce à l'implémentation de la méthode getCacheTags(). Son nom est arbitraire alors, comme souvent, nous allons le préfixer du nom du module pour éviter les collisions. Comme précédemment, nous allons utiliser une méthode pour fusionner ce nouveau cache tag avec d'éventuels autres définis par la classe parente.

  /**
   * {@inheritdoc}
   */
  public function getCacheTags() {
    return Cache::mergeTags(parent::getCacheTags(), ['hc_announcement_settings']);
  }

Ensuite, il nous faut juste modifier légèrement le formulaire d'administration de l'annonce pour lui demander d'invalider ce tag lors de l'enregistrement. Pour cela, nous avons besoin de faire appel au service cache_tags.invalidator que nous allons ajouter à notre injection de dépendances et à notre constructeur :

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

  /**
   * @var \Drupal\Core\Cache\CacheTagsInvalidatorInterface
   */
  protected $invalidator;

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

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

Ceci étant fait, il ne nous reste plus qu'à ajouter une petite ligne dans la méthode submitForm() pour provoquer l'invalidation.

$this->invalidator->invalidateTags(['hc_announcement_settings']);

Un dernier "petit" problème

Désormais, notre bloc est mis en cache suivant une logique qui s'appuie sur le mécanisme d'âge maximum pour définir quand l'expiration a lieu de façon très précise. Nous nous attendons donc à ce que le bloc apparaisse ou disparaisse approximativement au moment indiqué et ça fonctionne particulièrement bien... pour les utilisateurs authentifiés...

Le module Internal Page Cache du cœur permet de mettre en cache les pages entières à destination des anonymes afin d'améliorer drastiquement les performances. Le problème, c'est que ce cache, très agressif, ne tient pas actuellement compte des métadonnées de cache et notamment pas du max-age. En attendant que le cœur change de fonctionnement, vous pouvez contourner ce problème en installant le module Cache Control Override, qui ne nécessite aucune configuration particulière.

Conclusion

Au terme de cette paire d'articles, vous devriez y voir plus clair sur la façon de créer un formulaire et un bloc ainsi que sur la gestion du cache. Par cet exemple concret, j'espère que j'aurai réussi à vous faire visualiser des concepts qui étaient traités de façon bien plus académique dans nos précédents articles. S'il reste des zones d'ombre ou si vous voulez en savoir plus sur un point en particulier, n'hésitez pas à vous manifester dans les commentaires ci-dessous.

 

Crédit photo de couverture : Sue Cro

Catégories
Développement
Drupal
Drupal 8
Tags
state api
cache
blocs
Par Artusamak
Julien Dubois

Créer un système d'annonces simple avec Drupal 8

Créer un système d'annonces simple avec Drupal 8
DuaelFr
jeu 22/11/2018 - 16:56

Développé initialement pour ce site, notre système d'annonce simple regroupe plusieurs concepts intéressants à mettre en valeur dans un article en deux parties. Ici, nous évoquerons la réflexion autour du stockage de l'information et la construction du formulaire.

Corps

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.

Capture d'écran du formulaire ne présentant qu'un bouton de validation.

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.

Capture d'écran du formulaire présentant tous les champs définis par le code : activation de l'annonce, date de début, de fin, titre et contenu.

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.

Champ date de fin en erreur indiquant que sa valeur doit être supérieur ou égale à la date de début.

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 !

Formulaire de configuration de l'annonce complet affichant tous les champs ainsi que leurs données actuelles.

 

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

Catégories
Développement
Drupal
Drupal 8
Tags
state api
formulaires
configuration
entités
Par Artusamak
Julien Dubois

Installer Drupal depuis la configuration

Installer Drupal depuis la configuration
DuaelFr
jeu 15/11/2018 - 09:30

Depuis Drupal 8.6.0 il est possible d'installer un site depuis un ensemble de fichiers de configuration, voyons comment cela fonctionne.

Corps

Depuis la sortie de Drupal 8 et de son système de gestion de la configuration, la communauté n'a cessé de demander à ce qu'il soit possible de procéder à une installation complète à partir d'un jeu de fichiers de configuration existant. Il aura fallu plus de deux ans et des efforts considérables de dizaines de contributeurs et contributrices pour rendre cela possible.

Utilité

Cette nouvelle fonctionnalité, jusqu'à présent accessible avec un peu de bricolage grâce au profil d'installation Configuration Installer, ouvre de nombreuses possibilités. Tout d'abord, il y a les agences qui souhaiteraient avoir un socle pour démarrer rapidement leurs projets (c'est notre cas), mais aussi les développeurs et développeuses qui veulent pouvoir expérimenter des choses tout en étant capables de reconstruire rapidement leur environnement si besoin ou de monter des environnements de test à la volée. Côté fonctionnel cela rend également plus simple le clonage de site sans avoir à nettoyer les contenus et cela permet également, dans certains cas comme pour un système d'usine à sites, de disposer d'un socle minimal de configuration disponible lors de la création d'un nouveau site.

Préparation

Comme vous vous en doutez, la première étape est d'avoir un jeu de fichiers de configuration disponible. Si ce n'est pas votre cas, faîtes une installation classique avec le profil d'installation minimal, activez quelques modules, changez quelques options dans l'administration du site, puis exportez la configuration via le backoffice (chemin : admin/config/development/configuration/full/export) ou via Drush (drush config:export).

Placez vos fichiers de configuration dans un répertoire prévisible, hors de votre DocumentRoot si possible. Par exemple, si vous suivez l'organisation proposée par le drupal-project, cela se fera dans un répertoire config/sync à la racine du projet. Puis, indiquez l'emplacement de cette configuration dans votre fichier settings.php (ou settings.local.php si vous en avez un) de façon relative à la racine de Drupal, c'est à dire à l'emplacement du fichier index.php. Par exemple :

$config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync';

Note : il est aussi possible de stocker cette configuration dans le répertoire config/sync de votre profil d'installation sans avoir besoin de modifier le fichier de settings. Cela peut être très utile dans le cadre d'une distribution (interne ou contribuée) mais, dans la plupart des cas, un répertoire indépendant sera préférable car il permettra de maintenir la configuration à jour plus simplement au fil du projet.

Utilisation

Une fois votre référentiel de configuration et vos fichiers prêts, vous n'avez plus qu'à installer votre site.

C'est possible de réaliser cette opération depuis l'interface graphique fournie par Drupal, comme illustré ci-dessous.

Écran d'installation de Drupal faisant apparaître l'option "Use existing configuration" qui permet d'installer le site en se basant sur la configuration existante.

Cela est également possible via Drush 9.4 ou supérieur grâce à l'option --existing-config de la commande drush site:install.

Limitations et dépannage

Attention ! À l'heure actuelle, cette fonctionnalité ne fonctionne pas avec les profils d'installation qui implémentent un hook_install. C'est pour cette raison que je vous ai conseillé de tester en utilisant le profil minimal. Cela sera sans doute amené à changer dans le futur puisque la communauté travaille actuellement sur cette problématique.

De plus, si vous décidez de créer votre propre profil d'installation (ce que je recommande chaleureusement, j'en parlerai dans un futur billet), faîtes bien attention à l'export du fichier core.extension.yml. En effet, celui-ci contient la liste de tous les modules activés, y compris votre profil qui est considéré comme un module, ainsi qu'une référence directe au profil avec lequel le site a été installé. Si vous avez procédé à une installation via le profil minimal, il faudra remplacer ce dernier dans le fichier par le nom machine de votre propre profil sous les clefs "module" et "profile". Si vous ne faîtes pas cette modification, l'installation échouera.

Extrait d'un différentiel de code illustrant le changement de profil dans le fichier core.extension.yml.

Et voilà ! Vous savez tout. Si vous tombez sur des cas étranges, n'hésitez pas à nous laisser un petit commentaire !

 

Crédit photo de couverture : Sally Wilson

Catégories
Développement
Drupal
Drupal 8
Tags
configuration management
profil d'installation
Par Artusamak
Julien Dubois

Driesnote – State of Drupal – Drupal Europe 2018

Comme régulièrement, voici un mini transcript de la keynote de Dries pour Drupal Europe 2018 visant à raconter l’état de l’art de Drupal.

Pourquoi sommes nous ici ? Car nous avons envie de construire un Drupal que les gens et nous aimons.

« Impact gives purpose »

L’impact de Drupal dans le monde réel, aide à se motiver et se rappeler dans les moments difficiles qu’on a un impact concret lorsque l’on se prend la tête avec les issues.

Il y a un plan pour y arriver : promouvoir Drupal, améliorer drupal pour les créateurs de contenu, les développeurs, les nouveaux venus. Chaque piste a des étapes intermédiaires. Et cela fonctionne !

I) State of Drupal

8.6.0 a été publié la semaine dernière… comme prévu ! Ce qui est nouveau depuis Drupal 8 mais toujours rassurant et efficace pour rassurer tout le monde.

Il y a de plus en plus de contributeurs et de modules stables sur la dernière année et surtout des actifs dans les initiatives du cœur.

12 initiatives officielles ont lieu en parallèle (est-ce trop ?). Voici un récap sur ces initiatives.

A/ Améliorer Drupal pour les créateurs de contenu

Se satisfaire de copier du texte depuis Word rendu à peu près normalement dans le contenu ne suffit plus. Les contributeurs passent plus de temps sur l’interface qu’avant.

Démo des initiatives : Layout, media, out of the box, workflow. (Contenu de la démo : édition de contenu en ligne, mise en page par article, utilisation du site de démo Umami, préparation de contenu pour mise en ligne plus tard (staging de contenu).

[ndr : C’est vraiment impressionnant comparé à ce que l’on avait il y a 2 ou 3 ans !]

B/ Améliorer Drupal pour les développeurs

Initiatives : Admin UI, API-first, Javascript modernisation

1 an s’est écoulé depuis le début de l’initiative sur la modernisation du JS. Les objectifs étaient d’améliorer l’expérience d’admin, moderniser les API internes et le JS, tisser plus de liens avec la communauté Javascript.

La communauté s’appuie maintenant sur des tests utilisateurs pour avoir une idée plus fiable des fonctionnalités sur lesquelles travailler et qui sont attendues par les utilisateurs.

Un rafraîchissement du thème d’admin est en cours pour redonner un coup de frais à l’admin en attendant le travail de fond sur la refonte complète de l’expérience d’admin.

Drupal va s’appuyer sur React-UI pour sa nouvelle expérience d’administration (et seulement son administration). Twig ou un autre framework JS peut et pourra toujours être utilisé en front.
Pour réussir, le module contrib JSON API est utilisé (il s’agit de l’initiative API-First) en attendant que le module soit mature pour intégrer le cœur.
L’équipe s’appuie sur un prototype pour faire la démo du projet, on peut y voir des formulaires plus réactifs, une expérience bien plus dynamique et fluide.
Ce travail a aussi permis de faire du nettoyage dans le code JS existant.

C/ Améliorer Drupal pour les nouveaux venus

Il y a 6 mois, une critique a été formulée sur le temps d’installation de Drupal pour un nouveau venu (plus de 20 clics et 15 minutes pour installer Drupal).
Le profil d’installation Umami permet d’avoir un site avec du contenu dès leur première installation pour expérimenter Drupal. Un gros travail d’amélioration de la documentation est en cours sur drupal.org.
La page de téléchargement de Drupal a été améliorée en ajoutant des liens pour apprendre à installer Drupal et le tester et en simplifiant des commandes.
Grâce à cela, 3 clics et 1 minute 20 suffisent maintenant pour avoir un Drupal testable !

D/ Améliorer Drupal pour les développeurs

Initiatives : Automatic updates, migrate, composer œ core, config management 2.0, security LTS.

Beaucoup de progrès, trop pour en parler correctement. Des billets de Dries suivront.

Gros plan sur Security LTS. Jusqu’à maintenant, les équipes ont 1 mois pour mettre à jour Drupal avant qu’une branche majeure ne soit plus maintenue.  (Lors de la sortie de 8.5.x, 8.4.x était maintenue pour un mois avant d’être dépréciée). Avec la sortie de Drupal 8.6.x, la version précédente sera maintenue 6 mois. La durée de vie d’une version majeure sera donc d’un an (6 mois de vie active + 6 mois supportés par l’équipe de sécurité) contre 7 mois précédemment.

Les prochaines étapes pour les initiatives actuelles
Les prochaines étapes pour les initiatives actuelles

E/ Promouvoir Drupal

L’équipe va avancer malgré le fait que 78k des 100k$ aient été levés pour faire la promotion de Drupal. Le première action a été la publication d’un communiqué de presse pour la sortie de la 8.6.0. Préparation d’une plaquette, de références et d’espace de collaboration en cours de travail.

Drupal 7, 8 et 9.

Drupal 8 a des dépendances externes. Symfony 3 sera déprécié en novembre 2021. La migration vers une nouvelle version de Symfony devra se faire en passant à Drupal 9 pour des raisons de rétro-compatibilité. Drupal 8 devrait donc être en fin de vie en novembre 2021. L’objectif est de laisser un an aux mainteneurs pour passer de Drupal 8 à Drupal 9. Un an est une durée courte mais la politique de gestion des versions a été modifiée pour simplifier ces transitions. Il faut un an pour préparer Drupal 9. Drupal 9 serait donc prévu pour 2020. Drupal 8.7.0 et 8.9.0 existeront pour sûr.
Fin de vie pour Drupal 7 en 2020 en théorie mais prolongé jusqu’à novembre 2021. Drupal LTS sera toujours présent pour 7 comme il existe pour 6.

d9

Drupal.org bascule sur Gitlab

Réduction de la barrière à l’entrée pour les contributeurs en passant à des contributions à base de pull requests plutôt que de patches. Ce changement sera majeur et vraiment une excellente nouvelle pour la communauté.

L’intégration va se dérouler en 3 temps :

  1. Phase 1 : Q4 2018 / bascule des dépôts Git vers Gitlab + revue de code via Gitlab
  2. Phase 2 : Q1-Q2 2019 / merge requests et édition de code en ligne (via le navigateur)
  3. Phase 3 : Un jour / Fonctionnalités complémentaires (graphs, CI/CD…)

Annonces complètes :

Et dernière info…

Il y aura une DrupalCon en Europe en 2019 et elle aura lieu à Amsterdam du 28 octobre au 1er novembre !

 

Par Artusamak
Julien Dubois

Drupal 8 : déclarer un champ extrafield calculé (computed field)

Drupal 8 : déclarer un champ extrafield calculé (computed field)
admin
lun 13/08/2018 - 07:25

Lorsque vous devez insérer un champ sur une entité mais que cette donnée est calculée et n'est pas saisie par l'utilisateur, vous avez le réflexe de penser à un extra field.

Corps

Lorsque vous devez insérer un champ sur une entité mais que cette donnée est calculée et n'est pas saisie par l'utilisateur, vous avez le réflexe de penser à un extra field. C'est un bon début mais pour appliquer un formateur de champ, vous serez limités car cela n'est pas possible ! Fort heureusement, une solution a été introduite dans Drupal 8, il s'agit des computed fields.

Comment cela fonctionne-t-il ?

Au lieu d'utiliser le hook_entity_extra_field_info(), vous allez cette fois déclarer un hook_entity_bundle_field_info() et allez déclarer un base field auquel vous direz qu'il est calculé et indiquerez la classe qui fournie ses données. Avec du code c'est plus simple :

/**
* Implements hook_entity_bundle_field_info().
*/
function hc_core_entity_bundle_field_info(\Drupal\Core\Entity\EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
  $fields = [];
  if ($entity_type->id() == 'node') {
    if ($bundle == 'blog') {
      $fields['blog_related_posts'] = BaseFieldDefinition::create('entity_reference')
        ->setLabel(t('Related posts'))
        ->setComputed(TRUE)
        ->setClass('\Drupal\hc_core\BlogRelatedPostsComputed')
        ->setDisplayConfigurable('view', TRUE);
    }
  }
  return $fields;
}

Avec ce code, si vous videz les caches, vous verrez apparaître dans la gestion de l'affichage de votre entité ce nouveau champ auquel vous pourrez appliquer les formateurs pertinents. Cela dépendra du type de données que vous aurez sélectionné sur lequel il se basera.

Jetons maintenant un œil à la classe qui fournit les données sources du champ.

Pour faire les choses simplement, je vous conseille d'étendre la classe de liste du type de données de votre champ (dans mon exemple je m'appuierai sur EntityReferenceFieldItemList) et nous utiliserons le trait dédié aux champs calculés (computed fields). La classe retourne les NIDs des nœuds qui partagent les mêmes catégories que le nœud actuellement consulté.

<?php

namespace Drupal\hc_core;

use Drupal\Core\Field\EntityReferenceFieldItemList;
use Drupal\Core\TypedData\ComputedItemListTrait;

class BlogRelatedPostsComputed extends EntityReferenceFieldItemList {
  use ComputedItemListTrait;

  /**
   * Computed related blog posts.
   */
  protected function computeValue() {
    $delta = 0;

    // It's a bit tricky, authors are not UIDs but NIDs because we are looking
    // for humans and humans are nodes, not users.
    $blog_categories = $this->getParent()->getValue()->get('field_category')->getValue();
    $blog_nid = $this->getParent()->getValue()->id();

    if (count($blog_categories) > 0) {
      foreach ($blog_categories as $category) {
        $category_ids[] = $category['target_id'];
      }

      $q = \Drupal::entityQuery('node')
        ->condition('type', 'blog', '=')
        ->condition('field_category', $category_ids, 'IN')
        ->condition('status', NODE_PUBLISHED, '=')
        ->condition('nid', $blog_nid, '<>')
        ->range(0, 5)
        ->sort('created', 'DESC')
        ->execute();
      if ($q) {
        foreach ($q as $rev => $r) {
          $this->list[$delta] = $this->createItem($delta, $r);
          $delta++;
        }
      }
    }
  }
}

Grâce au trait, on se concentre uniquement sur la récupération des valeurs qui nous intéressent et on utilise $this->createItem() pour remplir la collection de valeurs de $this->list.

Vous pourrez ajouter à cela quelques tags pour optimiser le rendu de vos données et vous voilà prêts à exploiter la puissance des champs calculés et rendus grâce à des formateurs de champs ! Plutôt simple, non ?

Catégories
Développement
Drupal
Drupal 8
Tags
formateur
champ
computed field
Par Artusamak
Julien Dubois

Les nouveautés de Drupal 8.4.0

Les nouveautés de Drupal 8.4.0
admin
jeu 16/11/2017 - 10:53

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.

null

Corps

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.

Évolution des boutons de publication de contenu entre Drupal 8.3 et 8.4.

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.

Catégories
Développement
Drupal
Drupal 8
Tags
cache
rétro compatibilité
media
Par Artusamak
Julien Dubois

Rendez-vous au Drupalcamp Lannion à la fin du mois

Rendez-vous au Drupalcamp Lannion à la fin du mois
admin
lun 16/10/2017 - 17:46

null

Corps

Nous tentons de ne jamais manquer une occasion de soutenir la communauté Drupal française, c'est toujours un moment de plaisir et de partage. C'est également un bon prétexte pour nous retrouver au sein de l'équipe et de voyager un peu. Alors si vous aimez ou êtes curieux de Drupal et serez du côté de Lannion du 27 au 29 octobre 2017, venez nous retrouver. L'événement est gratuit pour y participer et vous pourrez profiter d'un super repas pour 15 € si vous réservez dès maintenant.

N'attendez plus !

Logo du DCLannion

 

 

Catégories
Drupal
Tags
drupalcamp
Par Artusamak
Julien Dubois

Formation Drupal 8 : De Drupal 7 à Drupal 8 (Session novembre)

Formation Drupal 8 : De Drupal 7 à Drupal 8 (Session novembre)
admin
lun 02/10/2017 - 12:13

null

Corps

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 !

Catégories
Drupal
Drupal 7
Drupal 8
Par Artusamak
Julien Dubois

Driesnote – State of Drupal – Drupalcon Vienne 2017

Ce billet reprend des notes capturées sur le vif en écoutant la keynote de Dries de la Drupalcon Vienne 2017. Il est parfois difficile de faire des phrases complexes sur le vif. Veuillez m’en excuser !

Drupal progresse malgré la perception que l’on peut en avoir. Le projet est en bonne santé. Voici quelques chiffres qui illustrent cette tendance sur core et l’écosystème de la contrib : +22% issues fermées, +28% de contributeurs supplémentaires, +26% de sociétés impliquées. 45% des contributions à Drupal viennent d’Europe.

Rappel amical, les contribs peuvent aussi être faites hors code. 🙂

En 1 an, le nombre de projets stable a plus que doublé, passant de 600 à 1400 projets stables suite à l’incitation des mainteneurs à publier une version stable de leurs modules.

Quelques uns des modules les plus populaires ont atteint un état stable pour D8 : Panels, Commerce, Search API, CTools, Tokens, Pathauto. Mais il en manque encore : Backup & Migrate, OG, Rules, Feeds.

Concernant la montée de version de D7 à D8, il ne reste que 12 issues critiques pour avoir la migration de core terminée via Migrate. (Ce qui est toujours énorme…).

Release tous les 6 mois, super positifs. Modules expérimentaux avancent vers stable de release en release (media, layout discouvery, date time range, inline form errors)

Division du marché CMS et multiplication des solutions. Les technos hors Drupal majoritairement utilisées par les agences sont principalement JS (node, angular, react, vues.js)

Question : pour qui est drupal ?Ambitious digital experiences

De petit à grand site (blog, portfolio, brochure, community management, SMB site with integeration, omni channel website, multisite platform) => REACH

Drupal n’est plus pour les petits sites.

Drupal est maintenant pour le monde de l’entreprise ? Pas seulement (omnichannel website, multisite platform). C’est adapté mais il y a de la place pour les utilisateurs type petite boite (SMB site with integrations)

Drupal grandit et évolue.

Le constat est que l’administration de Drupal est vieillissante. Drupal est parfois difficile à utiliser, les mises à jour sont complexes et coûteuses. L’objectif est de changer cela.

Sur quoi se concentrer ?

1. De puissants outils de site building.

PEOPLE – Création du rôle du product owner + a UX designer Yoroy est core committer (premier non dev)

PROCESS – Commencement par le design & product management (besoin ? Chemin ok sur les priorités ?) / Initiatives non dév (media, layout, workflows) / Démo de layout et du start theme de Drupal. (Workspaces – Groupes de config / contenus à publier). Media in core (library browser)

TOOLS – Good UX is built with JS. Devs want modern JS

Reco 1 => Plus de découplé headless (API First)

Reco 2 => Rendre Drupal plus simple à utiliser / Augmenter les compétences d’experts JS pour Drupal (+ de compétences externes) / Dogfood web services APIs (utiliser nos API)

Reco 3 => Créer des nouvelles UIs pour prendre le pli et explorer des nouvelles voies de construire avec du JS

Tendance de fond pour créer des interfaces côté Client

2. Des mises à jour et de la maintenance plus simples.

Updates régulières (6 mois majeure, 1 mois mineure) / de +en + d’outils complexes (composer, git, extra libs)

Users want Auto updates. Complexe à implémenter mais c’est un challenge intéressant à relever qui en vaut la chandelle en le construisant en plusieurs étapes.

Cirage de pompes de CG

 

Par Artusamak
Julien Dubois

Contourner l'erreur : "The SQL storage cannot change the schema for an existing field"

Contourner l'erreur : "The SQL storage cannot change the schema for an existing field"
admin
mar 11/07/2017 - 09:02

null

Corps

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 Darraultvia Wikimedia Commons.

Catégories
Développement
Drupal
Drupal 8
Tags
configuration
fatal
Par Artusamak
Julien Dubois

Les nouveautés de Drupal 8.3.0

Les nouveautés de Drupal 8.3.0
admin
jeu 06/04/2017 - 18:30

Depuis le 6 avril 2017 la nouvelle version mineure de Drupal, 8.3.0, est disponible. Bien que de nombreuses initiatives se développent rapidement, le contenu du cœur n'a, cette fois-ci, pas énormément évolué.

null

Corps

Depuis le 6 avril 2017 la nouvelle version mineure de Drupal, 8.3.0, est disponible. Bien que de nombreuses initiatives se développent rapidement, le contenu du cœur n'a, cette fois-ci, pas énormément évolué. Comme pour la sortie de Drupal 8.2.0, cet article vous dévoilera les détails de cette nouvelle mise à jour.

Modules expérimentaux

BigPipe suite et fin

Après un an de développement et de tests, le module expérimental BigPipe est le premier à être reconnu comme stable et à intégrer officiellement le cœur. Celui-ci, dont on vous a déjà parlé à chaque version mineure depuis la 8.1.0, permet d'améliorer l'expérience des utilisateurs en réduisant le temps passé à attendre le chargement de la page en apparence. En effet, il fournit au navigateur du contenu à afficher le plus rapidement possible tout en continuant de calculer l'affichage des zones complexes ou spécifiques à l'utilisateur⋅rice en parallèle.

Particulièrement efficace dans le cadre d'un trafic d'utilisateur⋅rice⋅s connecté⋅e⋅s, BigPipe souffrait d'un défaut lorsqu'il fallait servir une page anonyme pour la première fois, avant même sa mise en cache. Heureusement, ce cas précis se résout maintenant très simplement à l'aide du module Sessionless BigPipe.

Workflows et Content Moderation

Dans le cadre de l'avancement de la Workflow Initiative qui vise à intégrer un système générique de gestion d'états et de transitions dans le cœur, le module Content Moderation a été créé et intégré en tant que module expérimental dans la version 8.2.0. Initialement, ce module ne permettait que de gérer un workflow de publication appliqué aux nœuds. Dans cette nouvelle mouture, tout le code générique concernant la création et l'organisation d'un workflow a été déplacé dans le module Workflow. Le module Content Moderation, lui, ne contient plus que le code spécifique pour gérer le workflow de publication des nœuds et, en bonus, des commentaires.

Avec ce nouveau découpage, de nombreux bugs ont été corrigés et une nouvelle interface d'administration, simplifiée, a été mise en place.

Layout Discovery et Field Layout

D'abord abandonnée lors de la phase de développement initial de Drupal 8, la Layout Initiative refait son entrée dans le cœur à l'initiative des mainteneur⋅euse⋅s de quelques uns des modules les plus utilisés de Drupal 7 : Display Suite, Field Group et Panels. En effet, lors du portage de leurs modules vers Drupal 8, tou⋅te⋅s ont dû commencer à développer le même type d'interface et ils et elles ont rapidement constaté qu'il serait préférable de faire converger leurs besoins communs pour mutualiser le code au sein du cœur. Ainsi est né le module Layout Discovery, qui permet de définir et de manipuler de nouveaux objets de configuration, associés à des templates, les Layouts. Une fois n'est pas coutume, Display Suite en a profité pour se décharger d'une partie de ses fonctionnalités dans le cœur, sous la forme du module Field Layout. Ce dernier permet, comme Display Suite en Drupal 7, d'organiser les champs des entités pour les placer dans diverses zones, définies par le Layout sélectionné.

Bien qu'en alpha, ces deux modules aux fonctionnalités relativement simples remplissent déjà plutôt bien leur office et n'ont à ce jour aucun bug majeur de connu.

Autres modules expérimentaux

Le module Migrate passe enfin en bêta ! Cela signifie que les tâches majeures ont été effectuées et qu'il proposera désormais des chemins de migration d'une version bêta à la suivante si jamais un changement devait casser la compatibilité descendante.

En parallèle, Migrate Drupal et Migrate Drupal UI avancent doucement. La migration de sites Drupal 6 vers Drupal 8 sera bientôt en bêta. Celle de sites Drupal 7 est toujours à la traîne mais c'est normal car les dites Drupal 7 ont encore de beaux jours devant eux.

On a pu également constater de nombreuses améliorations du côté du module Content Moderation pour rendre la modération disponible pour toutes les entités. Attention toutefois, du fait de son statut d'alpha, la version 8.3 ne contient pas de chemin de mise à jour depuis les versions antérieures !

Le module DateTime Range, nécessaire aux modules contribués de calendriers notamment, avance sûrement vers une version stable qui devrait arriver prochainement.

Enfin, les modules Settings Tray, Place Block et Inline Form Errors n'ont pas connu de changements majeurs depuis la dernier version mineure.

Améliorations pour les éditeur⋅rice⋅s

Du côté des créateur⋅rice⋅s de contenus, pas grand chose à se mettre sous la dent si ce n'est la mise à jour de la librairie CKEditor qui fournit l'éditeur de texte riche par défaut de Drupal 8. Celle-ci apporte un nouveau thème visuel, plus léger et moderne, permettant de se concentrer plus sur le contenu. Elle fait désormais également apparaître les raccourcis clavier des différents boutons lorsqu'ils sont survolés avec votre souris, elle s'ajuste automatiquement en hauteur à mesure que vous rédigez du contenu (jusqu'à une taille maximale lui permettant de tenir dans l'écran) et intègre enfin la possibilité de coller du contenu depuis le web ou depuis Word en préservant la mise en page ou en le purifiant (selon le bouton utilisé).

Hormis la mise à jour de l'éditeur, une petite nouveauté pratique fait son apparition dans l'édition rapide du contenu. En effet, les champs de type image permettent désormais de faire glisser une image directement dans le navigateur au lieu de passer par le bouton "Parcourir" (qui reste cependant accessible en cliquant directement sur la zone).

Améliorations pour les "site-builders"

Pour avoir à l'œil son site, Drupal dispose d'une page dans les rapports contenant un récapitulatif de l'état général du site. Cette page, nommée "Tableau de bord d'administration", contient des informations sur le serveur mais aussi sur diverses options de configuration importantes et sur des points d'attention généraux soulevés par le cœur et les modules. Auparavant, cette page était une longue liste de points classés par ordre alphabétique. Désormais, les informations les plus utiles sont mises en avant et sont classées par leur criticité.

Nouveau tableau de bord d'administration mettant en valeur les éléments les plus importants et permettant de savoir d'un coup d'œil rapide si tout va bien sur le site.

D'autres améliorations diverses ont été apportées à l'interface d'administration pour la rendre plus fluide :

  • la liste des vues a été refondue pour être plus homogène avec le reste des listes d'administration, la rendre plus lisible et compacte ;
  • dans toutes les listes d'administration, l'ordre des filtres a été calqué sur l'ordre des colonnes ;
  • les actions "Supprimer" sur les blocs, que ce soit dans la liste de tous les blocs ou dans les liens contextuels, ont été harmonisées pour éviter les mauvaises manipulations (certains liens désactivaient juste le bloc alors que d'autres le supprimaient totalement).

Améliorations pour les développeur⋅euse⋅s

Comme à chaque version mineure, les fonctionnalités liées au webservices ont fait un bond en avant :

Côté architecture et industrialisation, Drupal 8 incite les projets à utiliser le système de gestion de paquets Composer. C'est donc tout naturellement que le packagist de drupal.org a été ajouté au composer.json du cœur, de même que les types de packages drupal-module, drupal-theme, drupal-profile, drupal-drush, drupal-custom-module et drupal-custom-theme ont été ajoutés, permettant à Composer de placer les paquets dans les bons répertoires.

Enfin, côté code et notamment côté standards, la syntaxe de tous les arrays du cœur a été modernisée pour passer à la notation avec crochets. De plus, la majorité des constantes utilisées par le cœur ont été intégrées dans des classes pour éviter le risque de conflit avec des librairies tierces et respecter les bonnes pratiques de la profession.
 

 

Photo de couverture © Mark Robinson, retouchée par Happyculture

Catégories
Drupal
Drupal 8
Tags
expérimentation
module
migration
workflow
administration
layout
Par Artusamak
Julien Dubois

Happyculture aux Drupal Developer Days Séville

Happyculture aux Drupal Developer Days Séville
admin
ven 10/03/2017 - 14:31

Corps

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é !

Badge sponsor café pour les DDD 2017

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.

Catégories
Drupal
Tags
ddd
Par Artusamak
Julien Dubois

Les nouveautés de Drupal 8.2.0

Les nouveautés de Drupal 8.2.0
admin
mar 10/01/2017 - 09:45

Il y a trois mois de cela, le 5 octobre, sortait, à l'heure, la version 8.2.0 de Drupal, apportant une fois encore son lot de correctifs et quelques nouveautés.

null

Corps

Il y a trois mois de cela, le 5 octobre, sortait, à l'heure, la version 8.2.0 de Drupal, apportant une fois encore son lot de correctifs et quelques nouveautés. Comme notre précédent article sur les évolutions de Drupal 8.1.0, cet article s'attardera sur les points essentiels de cette mise à jour "mineure" de notre CMS favori.

Content Moderation

Petit nouveau dans les modules expérimentaux, Content Moderation est issu de la Workflow initiative et pose les bases de la mise en place de workflows dans Drupal. Qu'il s'agisse d'un processus de validation de publication de contenus ou d'un processus de commande sur un site e-commerce, la possibilité d'associer des états à des entités ouvre les portes à de nombreuses fonctionnalités. Content Moderation est un portage éclairé du module Workbench Moderation et est la première pierre qui amènera Drupal à proposer des expériences de publication innovantes comme la possibilité de préparer et prévisualiser l'évolution d'un site complet et pas juste d'une page de contenu.

Contrairement à ce que permettait Workbench Moderation sous Drupal 7, il est désormais possible avec ce module de définir précisément ses propres états et transitions et même de définir plusieurs workflows différents car il est possible de choisir quels états seront accessibles en fonction du type de contenu.

Date Range

Ce module fait revenir dans le cœur une fonctionnalité présente dans le module Date de Drupal 7. Elle consiste, pour un même champ de saisie de date, de permettre la saisie d'une date de début et d'une date de fin. Durant le développement de Drupal 8 et l'intégration de ce module dans le cœur, cette fonctionnalité avait été écartée sous prétexte qu'il suffisait de créer un second champ pour saisir la date de fin. Cependant, au fil du portage des modules exploitant ces données comme le module Calendar, les équipes se sont aperçues que ce choix était problématique et il a donc été décidé de réintégrer cette fonctionnalité dans le cœur pour cette version mineure.

Rien d'incroyable à montrer ici ; le module met à disposition un nouveau type de champ qui affichera deux widgets de saisie de date, respectant la configuration que vous auriez choisie comme pour un champ date classique.

Widget de saisie d'une date de début et de fin.

Outside-in

Il y a quelques mois, Dries, le créateur de Drupal, annoncait sur son blog vouloir moderniser l'expérience des éditeurs et site builders en améliorant la façon dont certains éléments sont administrés. Son billet se focalisait alors sur l'exemple des menus et des blocs qu'il aurait aimé rendre éditables directement via la partie publique du site, comme Drupal 8 le permet déjà pour les contenus via le module Quickedit. Entre le concept, appelé «outside-in», et la réalisation, le saut est immense mais, la communauté ayant bien réagi à cette idée, un groupe s'est organisé pour en planifier la réalisation. La tâche est loin d'être terminée mais cette version 8.2.0 a vu apparaître ses deux premières émanations : les modules Place Block et Settings Tray.

Place Block

Comme son nom l'indique, l'objectif de ce module est de simplifier le placement des blocs dans les régions. Une fois actif, il ajoute un bouton dans la barre d'administration qui permet de faire apparaître les régions existant dans le design et, pour chacune d'elles, d'y insérer un bloc. Une première fenêtre modale permet de choisir quel bloc insérer, et une seconde de le configurer plus finement. Actuellement, le module ne permet pas de déplacer les blocs ni de créer directement un nouveau bloc personnalisé dans les modales. Loin d'être satisfaisant, ce module a tout de même le mérite de poser les bases pour une fonctionnalité qui sera certainement très utile lorsqu'elle sera terminée.

 

Settings Tray

Pour aller plus loin et permettre l'édition des paramètres des blocs présents sur la page, et même parfois de certains paramètres leur étant rattachés, c'est le module Settings Tray qu'il faut activer. Ce dernier donne une nouvelle dimension au bouton "Edit" de la barre d'administration en lui permettant, en plus de faire apparaître les icônes liées aux liens contextuels, de rendre tous les blocs de la page administrable en place. En cliquant sur un bloc, une barre latérale s'ouvre et permet d'éditer directement les options de base comme le titre et parfois plus. Par exemple, les blocs de menus exposeront les éléments présents dans le menu, ainsi que les options d'affichage telles que la profondeur maximale à afficher. Autre exemple, le bloc affichant le nom du site et le logo donne aussi la possibilité de modifier ces informations directement depuis la barre latérale alors qu'elles ne sont habituellement pas du tout exposées au niveau de la configuration des blocs.

 

Autres améliorations diverses

Comme pour la version 8.1.0, cette nouvelle mouture contient des dizaines de corrections et d'améliorations diverses. On peut noter entres autres :

  • le passage du module expérimental Big Pipe d'alpha à bêta ;
  • l'amélioration de l'expérience d'édition par l'activation par défaut des révisions et la normalisation des modales de CKEditor ;
  • et la possibilité de supprimer facilement tous les contenus d'un type d'entité avant de désinstaller le module associé.Interface de désinstallation des modules faisant mention de la possibilité de supprimer tous les contenus liés.

Et pour les développeurs alors ?

Cette nouvelle version a été très orientée vers les web services (et ça continue, si l'on en croit l'actualité). Ainsi, outre le fait qu'il soit désormais plus simple d'utiliser des modes d'affichages pour les commentaires, l'accès REST aux entités de configuration a été amélioré et de nouveaux points d'accès ont été créés pour permettre à un utilisateur de s'authentifier, s'inscrire et se déconnecter. En bonus, la mise en cache des pages 404 et des fils d'Ariane a été améliorée pour éviter de saturer les serveurs sur des sites à fort trafic.

À l'heure où j'écris ces lignes, nous approchons de la bêta de Drupal 8.3.0 qui figera les fonctionnalités ajoutées dans la prochaine mouture et tout ce que l'on peut dire pour le moment c'est que c'est très prometteur ! Rendez-vous après le 5 avril pour faire le point !

 

Crédits : couverture créée par Sacha Chua, modifiée par Happyculture

Catégories
Drupal
Drupal 8
Tags
expérimentation
module
migration
workflow
administration
Par Artusamak
Julien Dubois

Les nouveautés de Drupal 8.1.0

Les nouveautés de Drupal 8.1.0
admin
lun 28/11/2016 - 09:30

Mieux vaut tard que jamais. Avec le nouveau modèle de numérotation des versions de Drupal est apparue la possibilité d'ajouter des fonctionnalités pendant la vie d'une version majeure.

null

Corps

Mieux vaut tard que jamais. Avec le nouveau modèle de numérotation des versions de Drupal est apparue la possibilité d'ajouter des fonctionnalités pendant la vie d'une version majeure. Alors que nous fêtons le premier anniversaire de Drupal 6 et que Drupal 8.1.0 a déjà plus de 6 mois, il est plus que temps de faire le point sur les nouveautés que cette version a apporté pour la plupart sous la forme de modules expérimentaux.

BigPipe

Il y a 8 mois de ça, dans mon article sur l'incroyable cache de Drupal 8, j'évoquais déjà l'existence du module BigPipe, inspiré de la technique inventée par Facebook pour permettre aux utilisateurs de voir un premier rendu de la page, même incomplet, bien plus rapidement et ainsi avoir la sensation que le site se charge plus rapidement. En deux mots, cette technique repose sur le fait de remplacer les parties de la page complexes à calculer par des espaces vides et de les remplacer à la volée après que le contenu principal a été chargé.

La grande nouveauté à propos de ce module est simplement qu'il a été intégré dans le cœur de Drupal et permet donc à tou⋅te⋅s les courageux/ses d'en bénéficier à leurs risques et périls.

Inline Form Errors

Afin de satisfaire les exigences de la norme WCAG en terme d'accessibilité, Drupal a fait le choix de rassembler toutes les erreurs survenues à la soumission d'un formulaire dans un seul message en haut de page. En effet, il est important pour les personnes souffrant de problèmes visuels et utilisant un lecteur d'écran d'avoir un point d'entrée unique pour comprendre pourquoi leur soumission ne s'est pas déroulée comme prévu. Pour les personnes n'ayant pas ce type de problème, l'ergonomie de ce rassemblement de messages laisse à désirer car il est difficile de comprendre le contexte lié aux erreurs.

Avec Inline Form Errors il est désormais possible de proposer des messages ciblés tout en maintenant l'accessibilité. Ce module dispose chaque message à proximité du champ ayant généré l'erreur et utilise la zone centralisée, destinée aux malvoyants, pour afficher un message d'erreur générique pourvu de liens renvoyant vers chaque champ à corriger.

Illustration des différences entre les erreurs sans et avec le module Inline Form Errors

Migrate, Migrate Drupal et  Migrate Drupal UI

Note : Migrate Drupal UI s'appelait à l'origine Drupal Upgrade UI mais a été renommé pour des raisons de cohérence.

L'une des promesses du développement de Drupal 8 était de permettre de simplifier la mise à jour d'un site en Drupal 6 ou 7 vers Drupal 8. Malheureusement, la complexité d'une telle tâche n'a pas permis aux contributeurs de fournir les outils nécessaires à temps pour la sortie de la version stable. Tout d'abord, en lieu et place de l'ancienne méthode de montée de version, il a été décidé de s'appuyer sur le module Migrate, présent dans l'écosystème depuis déjà plusieurs années, en l'étendant pour qu'il soit en mesure de traiter nativement toutes les données nécessaires. 

Avec Drupal 8.1.0, les équipes de développement du cœur ont enfin eu le temps de finaliser une première version de ces outils et de les intégrer. Cette suite de modules sert donc de socle aux équipes de développement et permet même de convertir la configuration et le contenu d'un site très simple sans une ligne de code. En prime, la présence de Migrate dans le cœur permet également de procéder à des imports de contenus venant d'autres sources comme d'un autre CMS ou d'une base de données indépendante. Dans ce dernier cas, on s'appuiera volontiers sur des modules contribués comme Migrate Source CSV, Migrate Plus et Migrate Tools pour aller encore plus loin.

Pour en savoir plus, vous pouvez consulter le replay du webinar sur les problématiques liées à la migration de contenu et à la montée de version que nous avons tenu par deux fois en collaboration avec Kaliop.

Capture d'écran de la page de récapitulatif des capacités de migration pour un projet donné

Autres améliorations diverses

Outre ces quelques modules expérimentaux, le reste des fonctionnalités de Drupal a continué d'évoluer afin de proposer des nouveautés qui, même si elles semblent parfois minuscules, contribuent à se rapprocher des besoins de notre industrie.

Choix de la langue lors de l'installation

Cette fonctionnalité qui devait être présente dès Drupal 8.0.0 avait été désactivée en raison d'un trop grand nombre de bugs. Depuis Drupal 8.1.0 il est donc possible d'installer Drupal directement dans une autre langue que l'anglais, en profitant des traductions de la communauté.

Choix de la langue dans l'éditeur de texte riche

Certains sites jonglent dans une même page entre plusieurs langues. Dans le but de satisfaire aux exigences des normes d'accessibilité, il est important de pouvoir spécifier qu'une partie du contenu est dans une autre langue que la page. Ce nouveau plugin pour l'éditeur de texte riche propose de choisir la langue du texte en cours de frapper via un menu déroulant.

Capture d'écran du sélecteur de langue de l'éditeur de texte riche

Correction orthographique dans l'éditeur de texte riche

Les éditeurs de texte riche étant de petites applications, elles regorgent d'options. Cette modification est l'une des plus petites réalisées dans cette nouvelle version mais son impact est sensible. En 2 lignes de code il s'agit de permettre au navigateur d'accéder au texte inscrit dans l'éditeur pour y appliquer son système de correction orthographique.

Capture d'écran du correcteur orthographique dans l'éditeur de texte riche

Évolutions à destination des développeurs

Bien évidemment, outre les évolutions fonctionnelles, Drupal a aussi beaucoup avancé du point de vue du code et de l'expérience développeur (DX). Voici une petite liste non exhaustive des nouveautés que l'on peut retrouver dans cette version :

 

À suivre avec les nouveautés de la version 8.2.0… dans moins de 6 mois c'est promis ;)

 

Photo de couverture © Frank Taillandier

Catégories
Drupal
Drupal 8
Tags
expérimentation
module
migration
bigpipe
accessibilité
expérience utilisateur
Par Artusamak
Julien Dubois

Alors comme ça t'es développeur ?

Alors comme ça t'es développeur ?
admin
mar 08/11/2016 - 15:39

null

Corps

A chaque fois que l'on démarre une formation, on fait un petit tour de table pour que chacun se présente et nous parle un peu de son expérience. C'est une super occasion de briser la glace et de mettre tout le monde en confiance. Pour moi c'est aussi un bon prétexte pour picorer des bribes d'informations qui me serviront à lancer la conversation par la suite et à rebondir avec mon contenu. Parmi nos pré-requis de formation (et son intitulé) figure la mention "pour développeur Drupal". Oui mais voilà, ça veut dire quoi un développeur Drupal ?

C'est là que les choses se compliquent. Dans chaque société que l'on croise, la fiche de poste du développeur Drupal a un périmètre (très) variable. Je ne suis pas sûr qu'il y ait une bonne réponse parmi tous les cas d'usage mais au final j'ai le sentiment que cela se ressent un peu sur le marché. Les (vrais) développeurs Drupal finissent par être pénalisés car noyés dans la masse. Il en va de même sur la liste des critères de l'expert Drupal.

Regardons cette petite mise en scène qui se déroule il y a 2 ou 3 ans, les deux protagonistes sont Marc, un chef d'agence web et Thomas, un développeur PHP qui a déjà sauvé l'agence plusieurs fois pour des clients clés avec des demandes un peu trop tatillonnes le week-end.

Marc : Hey Thomas, viens me voir une seconde. Tu as vu l'email que je t'ai envoyé il y a cinq minutes ?
Thomas : Hmm, oui ? A propos du site vitrine avec Durpal ?
Marc : Ouais, Drupal, ouais. Le client a demandé à ce que l'on réponde avec et j'aimerais bien que tu te lances dessus pour qu'on se fasse les pieds.
Thomas : OK.

Quelques semaines plus tard, Thomas a réussi à mettre en ligne le projet en un temps record, faisant la fierté de Marc. Nos deux compères se croisent à la machine à café.

Marc : Bravo Thomas pour ta mise en ligne, c'est super. Le client est super content et t'as bien bossé.
Thomas : Merci Marc, content que ça plaise à tout le monde.
Marc : Dis moi, on est entrain de répondre à un plus gros projet avec Sarah d'ici la semaine prochaine et on pense que Drupal fera le job, tu pourras jeter un oeil ? T'es notre expert Drupal maintenant !
Thomas : Je dois mettre en prod MonSuperBoulanger.fr d'ici 10 jours, ça va être compliqué. Il fait quoi votre site ?
Marc : Oh bah les trucs classiques, de la gestion de contenu, un moteur de recherche de ressources, on a de la gestion de groupes et peut être que l'on doit importer les contenus de l'existant.
Thomas : Ah ouais quand même, bon ça devrait le faire alors. J'ai lu que Drupal savait faire ces trucs.

La réponse de l'appel d'offre part, par chance l'agence remporte le projet et voilà Thomas qui par la force des choses enchaine son deuxième projet. D'autres suivront jusqu'à cette fin d'année 2016 où le client historique de la boite souhaite refondre son site. Drupal 8 semble être le candidat idéal pour cette refonte mais Thomas ne connaît pas encore cette nouvelle version. L'esprit éclairé qu'est Marc lui propose alors de participer à la prochaine session de formation à Drupal 8 d'Happyculture.

La session de formation démarre, 4 participants ont répondu présent, Thomas est l'un d'eux et vient son tour de se présenter.

Thomas : Je suis Thomas, 29 ans, développeur Drupal, j'ai commencé Drupal en 2014 et j'ai uniquement fait du Drupal 7. Pour cette formation, j'attends de découvrir les nouveautés de Drupal 8 et de m'imprégner des bonnes pratiques du moment.

Nous y voilà, tous les participants nous racontent plus ou moins la même chose, tout le monde est impatient de découvrir Drupal 8. Lorsque l'on pose quelques questions, ils ont tous fait du développement avec Drupal. Et puis au fur et à mesure que la formation avance, lorsque l'on parle de paramètres de formateurs de champs, de types de champs personnalisés, de contrôleurs dédiés, de handlers de views, de types d'entités personnalisés, de cache etc on se rend compte que très rarement un participant a déjà fait tout (ou une partie de) cela. Alors on s'adapte car l'une des qualités les plus importantes dans la formation c'est la capacité à s'adapter faute de quoi on risquerait de s'emporter. Alors beaucoup de ces participants se présentent comme développeurs mais le sont-ils vraiment ?

Quels profils pour une équipe

Selon moi il y a 3 métiers dans l'écosystème Drupal. Je serai ravi d'en débattre avec vous si votre avis diffère.

Profil 1 : le thémeur

C'est à mon avis, le profil le plus rare sur le marché Drupal. Il s'agit d'une personne qui fait traditionnellement de l'intégration (ou du dév front-end si l'on veut être à la mode) et qui comprend le PHP pour extraire ses variables afin de les faire remonter dans ses .tpl.php si l'on parle de Drupal 7 ou dans les .html.twig si l'on parle de Drupal 8. Sa compétence première c'est l'intégration et le développement n'est pas sa priorité mais elle y porte un intérêt relatif pour comprendre ce qu'il est possible de faire. En cas de besoin, l'équipe aide cette personne à faire ce dont elle a besoin côté PHP.

Table avec des éléments créatifs éparpillés

Profil 2 : le développeur

Le vrai développeur est celui qui va s'appuyer sur les mécanismes d'extensibilité de Drupal pour créer des nouvelles briques si besoin, faire le modèle de données de son projet, concevoir l'application et faire les choix d'architecture. Il va tordre Drupal pour créer les nouveaux modules et modifier les existants afin de faire en sorte que Drupal s'adapte aux demandes du client, on parle aussi souvent de l'écriture de glue code. C'est lui qui est impliqué sur les composants "bas niveau" du site et qui maîtrise les APIs de Drupal.

Photo d'un clavier

Profil 3 : le site builder

Compétence peu répandue, peut être spécifique aux agences Drupal. Le profil de site builder est un profil qui connait extrêmement bien les options avancées, voire cachées, des modules contribués. Il sait quel module utiliser pour quelle situation, il s'appuie sur le travail du développeur pour mettre en oeuvre les nouvelles options exposées par les développeurs. Son arme principale : sa souris. Il clic à tout va à travers les nombreux écrans de Drupal. Si le développeur n'est pas disponible, il finira très souvent par trouver un module qui fait 80% de la fonctionnalité demandée.

Tour Jenga en gros plan

La complémentarité de ces trois profils vous donne une équipe technique robuste et capable de faire efficacement des sites avec Drupal. Hormis le développeur, les deux autres profils cités sont nécessaires et recherchés, n'ayez pas peur de vous revendiquer comme l'un d'entre eux si tel est le cas, vous vous ouvrirez certainement des portes. Beaucoup de personnes rentrent dans le monde de Drupal par le monde du site building (pour ne plus en sortir, rire machiavélique).

Et l'expert Drupal dans tout ça ?

Beaucoup de "développeurs Drupal" que l'on rencontre sont des personnes qui écrivent le glue code mais qui ne vont guère au-delà sans avoir trifouillé les entrailles de Drupal. C'est pour cela que le titre de "développeur drupal" paraît toujours ambitieux lorsque l'on creuse un peu plus. Concernant le titre d'expert Drupal, là... 

Que les choses soient claires, un expert, c'est quelqu'un qui maîtrise son sujet. S'il n'a pas une connaissance avancée du fonctionnement du coeur, de la gestion des performances et de la montée en charge, de comment faire un site multilingue, des mécanismes d'extensibilité, de l'inter-connexion avec des systèmes tiers, d'un peu de sécurité et qu'il n'a pas mélangé cela au cours de plusieurs dizaines de projets. Je pense que le titre d'expert Drupal est usurpé. L'Expert Drupal n'est pas un titre que l'on attribue à celui qui a le plus de projets dans les pattes et qui existe obligatoirement dans une société. Il est tout à fait possible que vous n'en ayez pas à la maison et par respect pour le poste, vous feriez mieux d'en avoir conscience. Si tout le monde s'autoproclame expert, qui l'est vraiment ? Et comment les clients peuvent-ils faire le tri ? Les certifications sont une piste de réponse possible. En attendant, essayons tous d'appeler un chat, un chat.

Catégories
Développement
Drupal
Tags
expert drupal
développeur drupal
thémeur
site builder

Pages