Drupal Paragraphs: Varianten, Abstände & Admin-UX | Droptica

Drupal Paragraphs tutorial, partie 2 : variantes, responsive design, espacement et UX admin

Drupal
Modules Drupal
Maciej Lukianski
Maciej Lukianski
13.07.2026

Ceci est la partie 2 et finale d’un guide en deux parties pour construire un site corporate basé sur des composants avec Drupal Paragraphs. À la fin de la série, vous aurez une bibliothèque de 10 à 12 types de paragraphes universels avec variantes de style, layouts responsives et contrôles d’espacement adaptés aux rédacteurs.

Ce Drupal Paragraphs tutorial, partie 2, transforme les composants de base de la partie 1 en une bibliothèque flexible et prête pour la production. Dans la partie 1, vous avez planifié une bibliothèque de composants réutilisables, configuré le socle Paragraphs et construit trois types centraux : Hero, Texte + Image et Feature Grid. Ils fonctionnent - mais ils sont rigides : un seul look, un seul layout. Ici, vous ajoutez tout ce qui rend une bibliothèque de composants flexible et maintenable pendant des années : variantes de couleur et de style, responsive design dédié, espacement contrôlé par les rédacteurs, champs conditionnels, une UX admin soignée et un plan pour la performance et l’évolution. Puis vous appliquez ces patterns au reste de la bibliothèque.

Ce guide suppose toujours Drupal 10 ou 11 et la configuration de la partie 1. Si votre setup Paragraphs frustre les rédacteurs, notre article Drupal Paragraphs : d’inutilisable à adapté aux rédacteurs explique ce qui sépare une implémentation cassée d’une qui fonctionne en production.

Dans cet article :

Qu’avez-vous construit dans la partie 1 ?

Dans la partie 1 de ce Drupal Paragraphs tutorial, vous avez établi une approche de planification (auditer les pages, identifier les patterns réutilisables, construire un minimum viable), installé Paragraphs, ajouté un champ de référence paragraphs à un type de contenu et adopté une convention de nommage de champs pour garder chaque type cohérent. Vous avez ensuite construit Hero, Texte + Image et Feature Grid avec leurs templates Twig et CSS de base.

Maintenant, vous rendez ces composants polyvalents.

Comment implémenter les variantes de couleur et de style ?

Une variante de style permet à un seul composant de s’afficher en plusieurs présentations visuelles - clair, sombre, brand, neutre - choisies par le rédacteur via un menu déroulant. C’est une fonctionnalité peu coûteuse qui augmente fortement la flexibilité perçue, car le même paragraphe peut paraître totalement différent selon le contexte, sans que personne ne touche au code.

Le mécanisme est un champ liste mappé sur une classe CSS. Ajoutez un champ liste field_style à chaque type de paragraphe avec ces options :

light|Light
dark|Dark
brand|Brand
neutral|Neutral

Lisez la valeur dans le template et appliquez-la comme classe modificateur sur le wrapper :

{% set style = content.field_style['#items'].value|default('light') %}
<section{{ attributes.addClass('paragraph', 'paragraph--hero', 'paragraph--style-' ~ style) }}>
  {# ... component markup ... #}
</section>

Structurez ensuite le CSS en styles de base plus surcharges de variantes, avec la palette définie une fois en custom properties :

:root {
  --color-light-bg: #ffffff;
  --color-light-fg: #1a1a1a;
  --color-dark-bg: #11151c;
  --color-dark-fg: #ffffff;
  --color-brand-bg: #0057ff;
  --color-brand-fg: #ffffff;
  --color-neutral-bg: #f4f5f7;
  --color-neutral-fg: #1a1a1a;
}

.paragraph--style-light   { background: var(--color-light-bg);   color: var(--color-light-fg); }
.paragraph--style-dark    { background: var(--color-dark-bg);    color: var(--color-dark-fg); }
.paragraph--style-brand   { background: var(--color-brand-bg);   color: var(--color-brand-fg); }
.paragraph--style-neutral { background: var(--color-neutral-bg); color: var(--color-neutral-fg); }

Comme chaque variante lit les mêmes custom properties, un rebrand devient une poignée de changements de valeurs plutôt qu’un passage dans chaque composant.

Pour une bibliothèque de dix types ou plus, répéter field_style sur chacun est fastidieux et source d’erreurs. L’alternative scalable est un plugin Paragraphs behavior, qui ajoute le réglage de style et sa logique de rendu à plusieurs types en une fois :

<?php

namespace Drupal\my_module\Plugin\paragraphs\Behavior;

use Drupal\paragraphs\Entity\Paragraph;
use Drupal\paragraphs\ParagraphsBehaviorBase;
use Drupal\Core\Form\FormStateInterface;

/**
 * @ParagraphsBehavior(
 *   id = "style_variant",
 *   label = @Translation("Style variant"),
 *   description = @Translation("Adds a color/style variant selector."),
 *   weight = 0,
 * )
 */
class StyleVariantBehavior extends ParagraphsBehaviorBase {

  public function buildBehaviorForm(Paragraph $paragraph, array &$form, FormStateInterface $form_state) {
    $form['style'] = [
      '#type' => 'select',
      '#title' => $this->t('Style'),
      '#options' => [
        'light' => $this->t('Light'),
        'dark' => $this->t('Dark'),
        'brand' => $this->t('Brand'),
        'neutral' => $this->t('Neutral'),
      ],
      '#default_value' => $paragraph->getBehaviorSetting($this->getPluginId(), 'style', 'light'),
    ];
    return $form;
  }

  public function preprocess(&$variables) {
    $paragraph = $variables['paragraph'];
    $style = $paragraph->getBehaviorSetting($this->getPluginId(), 'style', 'light');
    $variables['attributes']['class'][] = 'paragraph--style-' . $style;
  }

}

Activez le behavior sur les types de paragraphes qui doivent offrir des variantes - le sélecteur apparaît alors de façon cohérente partout. C’est l’approche que nous utilisons sur de vraies bibliothèques de composants, car elle garde les réglages transversaux au même endroit.

Lisez aussi : création de contenu flexible et facile avec le module Drupal Paragraphs et mode d’affichage des paragraphes - révision d’un module pour Drupal.

Comment construire des layouts responsives pour chaque paragraphe ?

Responsive ne signifie pas « la même chose, mais plus petite ». Chaque type de paragraphe a besoin de son propre layout mobile où le contenu est réorganisé et repriorisé pour un petit écran - pas seulement réduit.

Travaillez en mobile-first : écrivez le layout mobile une colonne comme défaut, puis ajoutez de la complexité aux breakpoints plus larges. Avec le composant Texte + Image de la partie 1 :

/* Mobile-first : empilé, image en premier. */
.paragraph--text-image {
  display: grid;
  gap: 1.5rem;
  grid-template-columns: 1fr;
}

/* Tablette et plus : deux colonnes. */
@media (min-width: 48rem) {
  .paragraph--text-image {
    grid-template-columns: 1fr 1fr;
    gap: 2rem;
    align-items: center;
  }
  .paragraph--text-image--right .paragraph--text-image__media {
    order: 2;
  }
}

Adoptez une stratégie de breakpoints cohérente sur toute la bibliothèque - par exemple une base mobile, un breakpoint tablette autour de 48rem et un desktop autour de 64rem - pour que les composants se comportent de façon prévisible ensemble.

Portez une attention particulière aux images. Utilisez les responsive image styles de Drupal pour que chaque breakpoint charge un fichier de taille adaptée, et envisagez l’art direction (un crop différent sur mobile) pour les visuels hero. C’est surtout utile quand vous remplacez du contenu basé sur des images par des paragraphes structurés : des composants correctement responsives apportent un gain immédiat en expérience mobile, vitesse de page et SEO. Testez sur de vrais appareils et à chaque breakpoint - pas seulement en réduisant la fenêtre du navigateur.

Comment ajouter un espacement contrôlé par les rédacteurs ?

L’espacement est le problème que tout système basé sur des paragraphes finit par rencontrer : deux sections au même fond s’empilent en un énorme gap, ou un paragraphe sans titre laisse une bande vide gênante. La solution : donner aux rédacteurs le contrôle de la marge et du padding par paragraphe, car l’espacement est contextuel et seul le rédacteur connaît le contexte.

Cette section vous donne une implémentation fonctionnelle à intégrer dans votre build tutorial. Pour la discussion complète sur pourquoi les layouts basés sur des composants développent des problèmes d’espacement, les compromis entre espacement automatique et manuel et les cas limites, voir notre deep dive sur l’espacement Drupal Paragraphs et les lacunes de layout.

Ajoutez deux champs liste - ou mieux, un behavior d’espacement - offrant la même échelle pour chacun :

none|None
small|Small
medium|Medium
large|Large

Exposez deux contrôles séparés. La marge éloigne un paragraphe de ses voisins ; le padding ajuste l’espace à l’intérieur. Les deux sont nécessaires, et les garder séparés rend le système vraiment flexible. Lisez-les dans le template comme classes modificateur :

{% set margin = content.field_margin['#items'].value|default('medium') %}
{% set padding = content.field_padding['#items'].value|default('medium') %}
{%
  set spacing = [
    'paragraph--margin-' ~ margin,
    'paragraph--padding-' ~ padding,
  ]
%}
<section{{ attributes.addClass('paragraph', spacing) }}>
  {# ... component markup ... #}
</section>

Définissez l’échelle une fois avec des custom properties pour rester cohérent partout :

:root {
  --space-s: 1.5rem;
  --space-m: 3rem;
  --space-l: 5rem;
}

.paragraph--margin-none   { margin-block: 0; }
.paragraph--margin-small  { margin-block: var(--space-s); }
.paragraph--margin-medium { margin-block: var(--space-m); }
.paragraph--margin-large  { margin-block: var(--space-l); }

.paragraph--padding-none   { padding-block: 0; }
.paragraph--padding-small  { padding-block: var(--space-s); }
.paragraph--padding-medium { padding-block: var(--space-m); }
.paragraph--padding-large  { padding-block: var(--space-l); }

Testez les contrôles sur les scénarios qui reviennent toujours : deux paragraphes blancs empilés (le rédacteur met la marge supérieure du second à none), un paragraphe sans titre (réduire le padding d’un cran) et une image full-bleed (padding à zéro). Recommandez les contrôles rédacteur plutôt que des règles CSS automatiques - l’espacement automatique change des choses que les rédacteurs ne voient pas ou ne prévoient pas, et la prévisibilité maintient leur confiance dans le système.

Comment utiliser les champs conditionnels et les valeurs par défaut intelligentes ?

Un long formulaire avec tous les champs visibles à la fois submerge les rédacteurs. Les champs conditionnels n’affichent les options que quand elles sont pertinentes - la progressive disclosure réduit la charge cognitive.

La Form API de Drupal core supporte la visibilité conditionnelle via #states. Par exemple, affichez un champ « Custom background color » seulement quand le style est réglé sur une option custom :

function my_module_form_alter(&$form, $form_state, $form_id) {
  if (isset($form['field_custom_bg'])) {
    $form['field_custom_bg']['#states'] = [
      'visible' => [
        ':input[name="field_style"]' => ['value' => 'custom'],
      ],
    ];
  }
}

Pour les non-développeurs qui configurent cela via l’UI, le module contrib Conditional Fields fournit le même comportement sans code. Dans les deux cas, le principe est le même : masquez ce qui n’est pas encore nécessaire.

Associez les champs conditionnels à des valeurs par défaut intelligentes. Présélectionnez le style le plus courant et medium pour l’espacement, pour qu’un paragraphe soit correct dès son ajout. La plupart des rédacteurs accepteront les défauts la plupart du temps - c’est exactement ce que vous voulez, le chemin facile doit produire un bon résultat.

Comment construire les types de paragraphes restants ?

Avec variantes, responsivité et espacement en place, le reste de la bibliothèque est une répétition avec intention. Appliquez la même recette - champs minimaux, variante de style, contrôles d’espacement, layout mobile-first - à chaque type restant : CTA Block, Cards, Testimonial, FAQ et Stats.

Deux exemples rapides.

CTA Block - field_heading, field_text, field_cta, plus le behavior de style :

<section{{ attributes.addClass('paragraph', 'paragraph--cta') }}>
  <div class="paragraph--cta__inner">
    {% if content.field_heading|render|trim %}
      <h2>{{ content.field_heading }}</h2>
    {% endif %}
    {{ content.field_text }}
    {{ content.field_cta }}
  </div>
</section>

Stats / Numbers - un type stats référençant des paragraphes stat_item répétés (field_value, field_label), rendu comme une rangée responsive :

.paragraph--stats__items {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr;
}
@media (min-width: 48rem) {
  .paragraph--stats__items {
    grid-template-columns: repeat(4, 1fr);
  }
}

Documentez chaque type au fil de la construction - son rôle, ses champs et ses variantes. Un court document vivant de la bibliothèque de composants évite que deux développeurs créent des versions légèrement différentes du même type, et sert de référence aux rédacteurs et designers. Le même mindset composants qui a guidé la planification en partie 1 s’applique ici : chaque type doit être assez universel pour se combiner sur de nombreuses pages, pas sur mesure pour un seul layout.

Comment améliorer les contrôles rédacteur et l’UX admin ?

Le formulaire admin est le CMS pour les rédacteurs. S’il est confus, tout le système paraît confus - traitez l’expérience d’édition comme un livrable, pas comme une réflexion après coup.

Commencez par les fondamentaux sur chaque type de paragraphe :

  • Ordre logique des champs. Mettez les champs les plus utilisés en premier : titre, puis image, puis corps, puis options comme style et espacement. Configurez cela dans « Manage form display » du type.
  • Texte d’aide sur chaque champ. Une ligne de description supprime les approximations. Dites aux rédacteurs à quoi ressemble le style « Brand » ou quel ratio d’image fonctionne le mieux.
  • Valeurs par défaut intelligentes. Présélectionnez la variante de style la plus courante et le nombre de colonnes, pour que les rédacteurs ne changent que le nécessaire.
  • Noms de types descriptifs. « Section hero avec image » se lit mieux dans le menu d’ajout que « hero_v2 ».

Installez ensuite un thème admin moderne - Gin transforme l’expérience d’édition en quelques minutes et est l’un des changements au meilleur ROI sur tout site Drupal :

composer require drupal/gin
drush theme:enable gin -y
drush config:set system.theme admin gin -y

Gin améliore l’expérience d’édition Paragraphs elle-même - boutons d’ajout plus clairs, meilleur drag-and-drop et formulaire plus propre - ce qui soutient directement l’approche adaptée aux rédacteurs sur laquelle repose toute la bibliothèque. Allez plus loin avec quelques touches avancées :

  • Icônes de types de paragraphes. Ajoutez une icône à chaque type pour un menu d’ajout scannable d’un coup d’œil.
  • Limiter les types disponibles par type de contenu. Dans l’affichage formulaire du champ paragraphs, restreignez les types que les rédacteurs peuvent ajouter sur un type de contenu donné - une landing page et un article d’actualité n’offrent que les composants pertinents.
  • Une expérience d’ajout claire. Utilisez le mode modal ou menu déroulant pour que les rédacteurs sachent exactement ce qu’ils insèrent. Pour les power users, des modules comme Geysir permettent une édition in-place plus rapide.
  • Styling admin personnalisé. Un peu de CSS ciblant les formulaires de paragraphes - regrouper les champs liés, resserrer l’espacement - rend les longs formulaires plus faciles à parcourir.

L’objectif est une interface assez intuitive pour que les rédacteurs soient productifs sans atelier de formation. La meilleure passation est une page exemple remplie sur staging, pas un manuel.

Quels aspects de performance comptent pour les pages basées sur des paragraphes ?

Les pages basées sur des composants peuvent devenir lourdes en médias - intégrez la performance dès le départ plutôt que de la rajouter plus tard.

  • Lazy-load des médias. Différez les images hors écran pour que le premier rendu reste rapide. Drupal moderne ajoute loading="lazy" aux champs image - vérifiez-le pour les médias intégrés dans les paragraphes.
  • Cacher efficacement. Les pages basées sur des paragraphes profitent du render cache de Drupal ; assurez-vous que vos templates et behaviors custom déclarent les bons cache tags et contexts pour que les pages restent en cache tout en se mettant à jour quand le contenu change.
  • Optimiser les images par variante. Une section à fond sombre peut nécessiter un traitement d’image différent d’une section claire - servez des fichiers de taille et compression adaptés via les responsive image styles.
  • Mesurer. Lancez Lighthouse avant et après, en surveillant Largest Contentful Paint et Cumulative Layout Shift, et traitez les régressions comme des bugs.

Remplacer du contenu basé sur des images par des paragraphes structurés et responsives est déjà un gain de performance - du vrai HTML charge plus vite et se reflow proprement là où un graphique lourd ne le pourrait pas.

Comment maintenir et faire évoluer la bibliothèque de composants ?

Une bibliothèque de composants est un actif de longue durée - designez-la pour grandir. Le signe d’un système sain est qu’ajouter un nouveau type ou une nouvelle variante ne requiert jamais de restructurer les existants.

Quelques pratiques la gardent maintenable :

  • Ajouter des types sans en casser d’autres. Chaque type de paragraphe est autonome, les nouveaux s’intègrent proprement. Résistez au CSS partagé qui se propage entre composants - appuyez-vous sur les échelles de custom properties.
  • Versionner vos templates. Gardez les changements de templates et behaviors en revue de code et gestion de configuration, pour que les modifications soient délibérées et réversibles.
  • Documenter la bibliothèque. Maintenez une référence vivante de chaque type, de ses champs et de ses variantes. C’est ce qui empêche deux développeurs de construire des composants quasi doublons.
  • Savoir quand refactorer vs ajouter. Si une nouvelle exigence est une variante d’un type existant, étendez-le. Si elle est vraiment différente, ajoutez un nouveau type. Évitez les deux extrêmes : un cimetière de types uniques et un méga-composant surchargé qui essaie de tout faire.

Ajoutez de nouveaux types selon la demande réelle, pas la spéculation. Quand les rédacteurs utilisent les composants d’une façon que vous n’aviez pas prévue - réutiliser une section produit pour promouvoir un événement, par exemple - c’est le signal que votre architecture fonctionne, et un guide pour la suite à construire.

Vous voulez construire un site Drupal basé sur des composants avec Paragraphs ?

Ce Drupal Paragraphs tutorial s’appuie sur des patterns que nous utilisons sur des rebuilds corporate en production - étendre une bibliothèque planifiée avec variantes de style, layouts responsives, espacement contrôlé par les rédacteurs et UX admin que les équipes contenu peuvent exploiter sans formation. Sur deux parties, vous êtes passé d’une installation Drupal vierge à un site corporate basé sur des composants prêt pour la production : une bibliothèque de types de paragraphes universels auxquels les rédacteurs font confiance et une codebase que les développeurs peuvent maintenir pendant des années.

Vous construisez un site Drupal basé sur des composants et voulez des experts sur l’architecture ? Notre équipe conçoit et construit quotidiennement des systèmes Paragraphs adaptés aux rédacteurs - des templates Twig et behavior plugins aux contrôles d’espacement et à la maintenance long terme. Visitez notre agence Drupal pour voir comment nous pouvons vous aider.

Check related blog posts