Comprendre les thèmes sous Drupal 8

1
1647
Comprendre les thèmes sous Drupal 8

Drupal 8 est dans les starting blocks et apporte son lot de nouveautés touchant tous les niveaux : site building, développement et theming. On peut citer quelques points fondamentaux comme l’utilisation de composants Symfony2, l’intégration de l’éditeur WYSIWYG CKeditor ou bien l’arrivée d’un outil de déploiement (Configuration Management). Plus particulièrement en ce qui concerne la couche de thème : quelles sont les nouveautés par rapport à la version 7? Comment s’adapter lorsque l’on connaît déjà Drupal ? Entrons dans le vif du sujet.

Ce que l’on voit d’un site Web dans un navigateur dépend de ce dernier, mais surtout du thème utilisé. Lorsque l’on souhaite créer un site Web, c’est classiquement que l’on a du contenu que l’on veut mettre en avant et partager, pour des raisons aussi bien artistiques que commerciales. On a donc deux aspects : le fonctionnel et la présentation. Le premier est de la responsabilité de Drupal et des modules, tandis que cette dernière relève du thème. Le theming est l’art de montrer.
Pratiquement, tous les modules produisent des données de façon générique; ils ont donc besoin de les afficher d’une façon ou d’une autre. Ils proposent pour ce faire des templates par défaut (par exemple le module node définit le hook de thème “node“ et son fichier de template node.html.twig). En pratique ils passent au système des données avec un certain formatage (via un render array).
Drupal doit alors déterminer quel est le “bon“ template à utiliser. Il y a le template par défaut mais il peut être surchargé et Drupal peut potentiellement en utiliser un plus précis dépendant du contexte. On parle de suggestion de hook de thème. On dispose de suggestions de base, mais aussi de suggestions ajoutées par le thème afin de disposer d’un template adapté à une situation bien particulière (par exemple en fonction du rôle de l’utilisateur, ou bien de l’heure courante…). Le système va d’abord chercher le template correspondant le mieux au contexte, puis s’il ne le trouve pas, utiliser le fichier par défaut (défini par le module correspondant).
Par la suite, Drupal va récupérer les données à formater, en donnant la possibilité à tous les modules et au thème de les altérer avant de les passer effectivement au template. Cette modification des données est réalisée par les différentes fonctions de preprocess. Le thème peut modifier ou ajouter en dernier des données à afficher, ce qui lui donne la main sur tous les modules.

TWIG

L’adoption de TWIG est un changement majeur par rapport aux versions passées de Drupal. TWIG est un langage de templating destiné aux intégrateurs. C’est une librairie externe qui a été intégrée à Drupal 8, remplaçant ainsi le moteur de thème PHPtemplate… TWIG utilise une syntaxe simple et lisible. L’abandon du PHP dans les fichiers de template est une très bonne chose : plus simple à lire et mieux sécurisé.
Versions avant D8 : l’affichage d’une variable sans contrôle de son contenu est un problème récurrent dans les templates utilisés avec Drupal 6 et 7.
En résultent des failles de sécurité de type Cross Site Scripting (XSS) dues à une connaissance trop superficielle du PHP qui n’est pas un langage destiné aux intégrateurs. TWIG pallie ce problème en échappant automatiquement le contenu des variables.Mais TWIG offre bien davantage, avec entre autre la possibilité de créer des filtres, de faire des boucles et des conditions, ou bien encore de traduire des chaînes de caractères. Notons également que la documentation officielle est très bien faite. Alors plus d’excuse pour ne pas s’y mettre!

BLOCS

D8 apporte ici des améliorations notables : Tout d’abord en généralisant le principe des entités et en l’appliquant au système de blocs : il est maintenant possible d’avoir plusieurs instances du même bloc et de créer des types de bloc fieldables (on peut ajouter des champs). Il est par exemple possible de retrouver un même bloc dans des régions différentes selon les pages.
De plus, le fil d’Ariane, les menus, les messages… désormais tout est bloc. On obtient ainsi un template de page ne contenant que les régions et les titres, le logo et le slogan du site. Cela semble logique avec le découpage de la page en régions dans lesquelles un administrateur peut positionner les blocs à volonté. Il est également possible de s’affranchir du fil d’Ariane, en n’assignant le bloc correspondant à aucune région du thème.

CSS

L’organisation des fichiers de CSS est du ressort du themeur, en tout cas du point de vue des noms et des styles de fichiers, Drupal 8 adopte l’architecture SMACSS (Scalable and Modular Architecture for CSS, smacss.com).
La gestion et le nommage des fichiers de CSS quant à eux, reviennent à l’intégrateur, facilitant les habitudes acquises sur d’autres systèmes.
Quelle que soit la version de Drupal, on constate que de nombreux fichiers sont plus ou moins bien nommés. C’est toujours le cas avec Drupal 8, mais le développeur est fortement encouragé à adopter l’architecture SMACSS. Cette dernière consiste à créer des fichiers de CSS en fonction du type de sélecteurs. Par exemple toutes les propriétés relatives aux balises HTML de base (souvent appelé reset ou normalize) doivent faire partie du groupe de fichier base. Lorsqu’il s’agit de styles propres à des éléments réutilisés sur l’ensemble du site (comme des éléments de formulaire ou des boutons), on préfère les réunir dans le groupe component (et non module comme défini par SMACSS, mais qui pose un problème de terminologie évident avec ce que l’on appelle module dans l’univers drupalien).

JS

Javascript est un incontournable du développement Web actuellement et Drupal 8 ne déroge pas à la règle. De très nombreuses bibliothèques et nouveaux frameworks sortent chaque semaine. Il n’est pas facile de faire coexister différentes librairies sur une même page Web car des conflits peuvent survenir comme par exemple des incompatibilités de versions ou bien un ordre de chargement inadapté.
Drupal 8 propose un gestionnaire de bibliothèques permettant d’unifier la déclaration et de gérer les dépendances. Le développeur indique simplement en quoi consiste sa librairie (version, fichiers, dépendances…) et à quel moment il en a besoin. Drupal s’occupe alors du chargement et des dépendances pour toutes les librairies nécessaires.
Drupal 8 continue l’intégration de bibliothèques externes entamée avec jQuery et Drupal 5. Nous disposons ainsi nativement de jQuery, jQuery UI, Backbone.js, ou encore CKEditor pour ne citer que certaines d’entre elles.
Le chargement se fait page par page; ainsi aucune librairie n’est chargée par défaut, en particulier pas jQuery.
Liste des librairies disponibles nativement :

backbone drupal.autocomplete
classList drupal.batch jquery.ui
ckeditor drupal.collapse matchmedia
domready drupal.debounce matchmedia.addListener
drupal drupal.dialog modernizr
drupalSettings normalize
drupal.active-link html5shiv picturefill
drupal.ajax jquery underscore
drupal.annonce jquery.cookie

Il est conseillé d’utiliser le mode strict dans ses propres scripts comme cela est le cas pour les librairies déclarées par le système. Ceci permet entre autre de lever des erreurs silencieuses qui peuvent engendrer des bugs. Globalement l’intégration du Javascript est plus «propre».

LIBRAIRIES

Déclaration : tous les assets doivent être déclarés sous forme de librairie. Il n’est plus possible de charger à la volée des CSS ou JS. Chaque librairie est un “objet“ avec un titre, une version, un ensemble de fichiers… et d’autres propriétés (licence, dépendance…). La déclaration se fait via un fichier YAML.

Extrait du fichier /core/core.librairies.yml
Extrait du fichier /core/core.librairies.yml

Le chargement d’une librairie n’est pas automatique. Il est nécessaire d’indiquer au système à quel moment vous en avez besoin. Il est possible de demander un chargement sur l’ensemble du site (via le fichier .info.yml du thème), ou bien ponctuellement, par exemple pour un bloc en particulier.
Drupal 8 propose un système de dépendances entre librairies et prend ainsi en charge leurs chargements. Si votre librairie nécessite jQuery, alors vous déclarez votre dépendance à cette librairie et Drupal la chargera chaque fois que votre librairie est utilisée.

BREAKPOINTS

Les breakpoints peuvent être déclarés au système et ainsi sortir du contexte simple du CSS. Ils sont définis dans un fichier dédié, au format YAML.
Ainsi Drupal peut les exposer côté back-end aux modules. C’est le cas du module Responsive Image (désinstallé par défaut) qui permet ainsi d’utiliser des styles d’image différents en fonction des breakpoints. On peut ainsi aborder l’Adaptive Design sereinement, en n’affichant pas forcément le même contenu sur la page d’accueil en fonction de l’appareil utilisé.

Fichier /core/themes/bartik/bartik.breakpoints.yml
Fichier /core/themes/bartik/bartik.breakpoints.yml

CONFIGURATION

Le thème et la configuration du site ne sont pas totalement dissociés. Certains thèmes permettent à l’utilisateur de paramétrer le site d’un point de vue “rendu“. Avec Drupal 8 la configuration est définie sous forme de fichiers YAML et stockée en base par le système. Par exemple chaque type de contenu, chaque style d’image ou chaque vue fait l’objet d’un fichier de configuration. Il est maintenant facile d’embarquer n’importe quel élément de configuration dans un module ou bien un thème. Il suffit d’exporter la configuration via le back-office de Drupal et de placer le fichier correspondant dans le dossier /themes/mon_theme/config/install.

Fichier /themes/mon_theme/config/install/image.style.mon_style.yml
Fichier /themes/mon_theme/config/install/image.style.mon_style.yml

C’est lors de l’installation d’un nouveau thème que Drupal importe la configuration.
Notez bien que cette configuration ne doit pas être déjà présente sur le site. Vous ne pouvez pas, par exemple embarquer le style d’image mon_style, si ce dernier fait partie de la configuration active. Le système de configuration de Drupal 8 ne fonctionne pas comme Features! On ne peut pas re-déclarer ou surcharger une configuration active.


Le système de theming de Drupal 8 s’est largement amélioré par rapport à Drupal 7, sans pour autant abandonner certains principes puissants (surcharge de template, suggestion de hook de thème…). Il s’est même simplifié en abandonnant par exemple les fonctions de thème et de process et en apportant une plus grande simplicité dans l’écriture des fichiers de template (merci TWIG). Les intégrateurs vont apprécier ces évolutions qui vont grandement leur faciliter le travail.

Comprendre les thèmes sous Drupal 8
5 (100%) 5 votes
PARTAGER SUR
Ayoub Belkadi
Ayoub Belkadi est un consultant et Freelance SEO. Il optimise des sites web pour atteindre la première page de Google en utilisant le référencement naturel Whitehat SEO. Il concois aussi des sites web sous la platforme Wordpress 100% responsive.