Divi Theme Builder : conditions d'affichage avancées par taxonomie et par rôle

Le constructeur de thème de Divi permet de définir des modèles pour l'en-tête, le corps et le pied de page, et de choisir sur quelles pages chacun s'applique. Cette dernière partie, les conditions d'affichage, est celle qui fait la différence entre un site simple et un site réellement structuré : afficher un en-tête différent sur une catégorie précise, un pied de page spécifique aux fiches produits, ou un bloc réservé aux membres connectés. Les possibilités dépassent largement le choix du type de contenu, et leur combinaison produit rapidement des conflits difficiles à diagnostiquer. Nous détaillons ici le fonctionnement des conditions, l'ordre de priorité entre modèles et la méthode pour construire un ensemble cohérent qui reste maintenable dans le temps.

Comment les conditions fonctionnent

Le principe est simple et ses implications le sont moins, en particulier lorsque plusieurs modèles peuvent s'appliquer à une même page. Le fonctionnement général de l'outil est présenté dans notre guide complet du Theme Builder de Divi.

Inclusion et exclusion

Chaque modèle porte deux listes : celle des contextes où il s'applique et celle des contextes où il ne s'applique pas. L'exclusion l'emporte toujours sur l'inclusion, ce qui permet de définir une règle large puis d'en retirer des cas. Cette logique est celle que l'on retrouve dans la plupart des systèmes de ciblage et elle reste contre-intuitive au premier usage. Écrire d'abord la règle large puis les exceptions produit une configuration plus lisible que d'énumérer chaque cas. Cette approche facilite également la maintenance lorsqu'un nouveau contenu apparaît. Elle constitue la bonne habitude à prendre dès le premier modèle, et elle évite les listes d'inclusion de trente entrées que personne n'ose plus toucher.

Les niveaux de ciblage disponibles

Les conditions couvrent le type de contenu, les contenus individuels, les taxonomies et leurs termes, les archives, les pages spéciales et les états de l'utilisateur. Cette variété permet un ciblage très fin et elle produit une combinatoire importante. Recenser les conditions réellement utiles au projet avant de commencer évite de construire un ensemble inutilement complexe. Trois ou quatre modèles couvrent la plupart des sites de contenu. Au delà de six ou sept, la maintenance devient une charge réelle. Cette limite pratique mérite d'être posée dès la conception.

Le ciblage par taxonomie

Cibler une catégorie, une étiquette ou une taxonomie personnalisée permet de traiter des ensembles de contenus sans les énumérer. C'est le mécanisme le plus utile en pratique, puisqu'il continue de fonctionner lorsque de nouveaux contenus sont créés. Il suppose que la structure de classification du site soit correctement pensée, sujet développé dans notre article sur la taxonomie WordPress. Un site dont les catégories sont mal conçues produira des conditions d'affichage bancales. Le travail sur la taxonomie précède donc celui sur les modèles. Cette dépendance est régulièrement ignorée.

Le comportement sur les termes enfants

Cibler une catégorie parente n'inclut pas nécessairement ses sous-catégories, comportement qui surprend et qui doit être vérifié. Le contrôle consiste à créer un contenu de test dans une sous-catégorie et à observer quel modèle s'applique. Selon la version, le comportement diffère, ce qui impose de ne pas se fier à une documentation ancienne. Lorsque l'héritage n'est pas assuré, il faut lister explicitement les termes enfants. Cette liste doit être mise à jour lors de la création d'une nouvelle sous-catégorie, contrainte de maintenance à documenter. Elle constitue un argument en faveur d'une taxonomie plate.

Le ciblage par état de l'utilisateur

Les conditions permettent de distinguer les visiteurs connectés des visiteurs anonymes, et parfois de cibler des rôles précis. Cette possibilité sert à afficher un en-tête différent aux membres, ou à masquer un bloc commercial aux clients existants. Elle relève du confort d'affichage et jamais de la sécurité : un contenu réservé doit être protégé par un contrôle de droits réel. Les rôles disponibles correspondent à ceux du système, présentés dans notre article sur l'utilisateur WordPress et ses rôles. Cette distinction entre affichage et protection doit être claire dans l'esprit de l'équipe. Elle évite des erreurs de conception coûteuses.

L'interaction avec le cache

Un modèle dépendant de l'état de connexion produit des pages différentes selon le visiteur, ce qui interdit une mise en cache indifférenciée. Servir depuis le cache une page destinée aux membres à un visiteur anonyme constitue un incident. Les extensions de cache proposent généralement une exclusion pour les utilisateurs connectés, qu'il faut activer. Ce point est la principale source de dysfonctionnement des conditions par rôle. Le contrôle se fait avec deux navigateurs, l'un connecté et l'autre non. Il prend deux minutes et il doit précéder toute mise en production.

Gérer les priorités entre modèles

Lorsque plusieurs modèles pourraient s'appliquer à une même page, un seul l'emporte, et la règle qui détermine lequel doit être comprise.

Du plus spécifique au plus général

La règle générale privilégie la condition la plus précise : un modèle ciblant un contenu individuel l'emporte sur un modèle ciblant sa catégorie, qui l'emporte sur un modèle ciblant tous les articles. Cette hiérarchie correspond à l'intuition et elle comporte des cas limites. Deux modèles de même niveau de spécificité produisent un comportement dépendant de leur ordre de création, ce qui est fragile. Éviter cette situation par conception vaut mieux que de tenter de la maîtriser. Une règle simple consiste à ne jamais créer deux modèles au même niveau visant des ensembles qui se recoupent. Cette discipline supprime la quasi totalité des conflits.

Le modèle par défaut

Un modèle sans condition particulière s'applique partout où aucun autre ne prend la main. Il constitue le filet de sécurité et il doit exister, faute de quoi certaines pages afficheront le gabarit du thème plutôt que le modèle construit. Ce cas produit une incohérence visuelle sur des pages rarement consultées, découverte tardivement. Vérifier qu'un modèle par défaut couvre bien tous les cas constitue un contrôle simple. Il consiste à parcourir chaque type de page du site et à observer le rendu. Cette revue prend un quart d'heure.

Les pages spéciales

La page de résultats de recherche, la page d'erreur et les pages d'archive par date relèvent de conditions dédiées. Elles sont fréquemment oubliées et elles apparaissent alors avec le gabarit par défaut du thème, souvent très différent du reste du site. Une page d'erreur incohérente donne une impression de site mal tenu au moment précis où le visiteur est déjà contrarié. Les traiter explicitement fait partie de la mise en place. Elles demandent chacune un modèle simple, parfois une simple variante du modèle général. Leur oubli constitue l'un des défauts les plus visibles.

Les types de contenu personnalisés

Un site utilisant des types de contenu créés par une extension doit prévoir des modèles pour chacun. Ces types apparaissent dans la liste des conditions, à condition que l'extension les déclare correctement comme publics. Un type non déclaré public n'apparaîtra pas, ce qui bloque le ciblage. Ce cas se rencontre avec certaines extensions et il se corrige par une déclaration dans le thème enfant. Le diagnostic n'est pas évident lorsqu'on ignore ce mécanisme. Il explique la plupart des situations où un type de contenu semble absent de la liste.

Documenter la matrice

Un tableau listant chaque modèle avec ses conditions d'inclusion et d'exclusion constitue le document de référence du projet. Sans lui, comprendre pourquoi une page affiche tel modèle demande de rouvrir chaque configuration. Ce tableau tient sur une page et il se met à jour à chaque modification. Il rend un service considérable lors d'une intervention ultérieure, y compris par une autre personne. Sa constitution prend une demi heure. Elle représente le meilleur investissement de tout le chantier.

Tester chaque combinaison

La vérification consiste à ouvrir un contenu de chaque type et de chaque catégorie et à confirmer que le modèle attendu s'applique. Cette liste de contrôle doit être écrite avant de commencer, puis déroulée après chaque modification. Elle révèle les recouvrements involontaires bien mieux qu'une relecture de la configuration. Sur un site comportant six modèles, elle comporte une quinzaine de vérifications. Elle prend vingt minutes et elle évite des découvertes désagréables. Elle mérite d'être conservée pour les évolutions futures.

Diagnostiquer un affichage inattendu

Le symptôme le plus fréquent est celui d'une page qui affiche un modèle autre que celui prévu, sans erreur ni message.

Identifier le modèle réellement appliqué

La première étape consiste à savoir lequel s'applique, information qui n'est pas affichée directement. Le code source de la page contient des identifiants permettant de la retrouver, et une comparaison visuelle avec chaque modèle tranche généralement en quelques secondes. Ajouter temporairement un texte distinctif dans chaque modèle rend l'identification immédiate. Cette technique de marquage temporaire est la plus efficace et elle demande de penser à retirer les marqueurs. Elle évite de raisonner sur des suppositions. Elle prend cinq minutes à mettre en place.

Vérifier les exclusions

L'exclusion l'emportant sur l'inclusion, une règle d'exclusion oubliée explique la plupart des cas où un modèle ne s'applique pas alors qu'il le devrait. Relire les deux listes de chaque modèle candidat révèle immédiatement le problème. Cette vérification est fastidieuse et elle est la plus productive. Le tableau documentant la matrice, s'il existe, réduit ce travail à une lecture. C'est précisément dans ces situations qu'il démontre sa valeur. Son absence transforme un diagnostic de cinq minutes en une demi heure.

Contrôler les recouvrements

Deux modèles ciblant des ensembles qui se croisent produisent un comportement dépendant de leur ordre interne, difficile à prévoir. Repérer ces recouvrements demande de comparer les conditions deux à deux. Sur un ensemble de six modèles, cette comparaison porte sur quinze paires, ce qui reste faisable. Elle révèle généralement un ou deux recouvrements involontaires. Les résoudre par une exclusion explicite rend le comportement déterministe. Cette opération constitue la correction la plus durable.

Écarter le cache

Une page servie depuis un cache conserve le modèle appliqué au moment de sa génération, même après une modification des conditions. Vider le cache et tester en navigation privée doit précéder toute conclusion. Ce contrôle est régulièrement omis et il explique une part notable des faux diagnostics. Le cache du constructeur s'ajoute à celui de l'extension de performance, ce qui impose de vider les deux. Cette étape prend une minute. Elle évite des recherches inutiles.

Tester avec un compte de chaque rôle

Lorsque des conditions dépendent de l'état de connexion, le comportement observé depuis une session administrateur ne reflète rien. Un compte de test par rôle concerné, conservé en permanence, rend ce contrôle rapide. Il faut également tester en session anonyme, cas majoritaire sur un site public. Cette triple vérification révèle les erreurs de ciblage par rôle. Elle prend quelques minutes et elle est indispensable dès qu'un espace membre existe. Son omission produit des incidents visibles par les visiteurs.

Isoler sur un contenu de test

Créer un contenu neuf, dans la catégorie concernée, permet d'observer le comportement sans les particularités accumulées sur un contenu existant. Certains contenus anciens portent des réglages individuels qui prennent le pas sur les modèles. Ce test tranche entre un problème de configuration générale et une particularité locale. Il demande deux minutes et il oriente complètement la suite. Il constitue le réflexe à adopter avant toute modification des conditions. Il évite de casser une configuration correcte pour un problème isolé.

Construire un ensemble cohérent

La qualité du résultat tient davantage à la conception d'ensemble qu'à la maîtrise de chaque condition prise isolément.

Partir des besoins réels

Lister les variations d'affichage réellement nécessaires, en interrogeant les personnes qui utilisent le site, évite de construire des modèles pour des besoins imaginaires. Beaucoup de sites comportent des modèles créés pour un cas ponctuel et jamais retirés. Ce recensement prend une heure et il réduit souvent le nombre de modèles envisagés. Chaque modèle supprimé simplifie durablement la maintenance. La question à poser pour chacun est simple : que se passe-t-il si on ne le crée pas. Une réponse floue signale un modèle superflu, et le supprimer coûte toujours moins cher que de le maintenir pendant cinq ans.

Privilégier la taxonomie au ciblage individuel

Cibler dix contenus individuels fonctionne le jour de la création et se dégrade dès qu'un onzième apparaît. Cibler une catégorie continue de fonctionner sans intervention. Cette différence de robustesse justifie parfois de créer une catégorie ou une étiquette dédiée uniquement pour le ciblage. Cette pratique est parfaitement légitime, à condition que la taxonomie ne soit pas affichée publiquement si elle n'a pas de sens éditorial. Une taxonomie technique, non publique, remplit parfaitement ce rôle. Elle se déclare en quelques lignes dans le thème enfant.

Limiter le nombre de modèles

Chaque modèle supplémentaire multiplie les combinaisons à tester et les conflits possibles. Un site de contenu fonctionne généralement bien avec un modèle d'article, un modèle de page, un modèle d'archive et un modèle par défaut. Les variations mineures se traitent par des règles de style conditionnelles plutôt que par un modèle distinct. Cette approche réduit considérablement la complexité. Elle demande d'accepter une légère perte de souplesse. Le compromis est presque toujours favorable.

Réutiliser les modules communs

Les blocs identiques entre plusieurs modèles doivent être enregistrés dans la bibliothèque en tant qu'éléments globaux. Une modification se répercute alors partout, au lieu d'imposer une reprise dans chaque modèle. Cette pratique évite les incohérences qui apparaissent inévitablement lorsque le même bloc est dupliqué. Elle constitue le principal levier de maintenabilité de ce type de construction. Son adoption doit être décidée dès le départ. La conversion a posteriori demande de reprendre chaque modèle.

Prévoir les performances

Un modèle chargé de modules produit un balisage volumineux et une feuille de style importante. Sur un modèle appliqué à toutes les pages du site, ce poids se paie partout. Mesurer le poids d'une page construite avec les modèles, comparé au gabarit du thème, révèle parfois un écart considérable. Simplifier les modèles les plus utilisés produit un gain sur l'ensemble du site. Ce contrôle est rarement effectué et il mérite de l'être. Il oriente les arbitrages de conception.

Vérifier après chaque mise à jour

Les conditions d'affichage sont sensibles aux évolutions du constructeur et à celles des extensions déclarant des types de contenu. Dérouler la liste de contrôle après chaque mise à jour majeure détecte les régressions. Cette vérification prend vingt minutes et elle évite qu'un modèle cesse silencieusement de s'appliquer. Sur un site comportant plusieurs modèles, elle mérite une place dans la procédure de mise à jour. Un environnement de test permet de la mener avant la production. Cette précaution est proportionnée à l'enjeu sur un site professionnel.