Modes d’affichage : modes de vue et de formulaire

04/07/2025, by Ivan

Modes d’affichage

Il existe des modes d’affichage (disponibles dans admin/Structure/Display-Mode) permettant de fournir différentes présentations des objets de contenu pour la consultation ou l’édition. Deux types de modes d’affichage existent : les « modes de vue » et les « modes de formulaire ». Ces deux types — modes de vue et modes de formulaire — sont des exemples d’« objets de configuration ». Voici un exemple d’export d’un mode de vue :

uuid: 15dc7aa9-13fd-4412-9c06-06d09f915d08
langcode: en
status: false
dependencies:
  module:
    - node
id: node.full
label: 'Contenu complet'
targetEntityType: node
cache: true

fichier : core.entity_view_mode.node.full.yml

La propriété principale à noter est targetEntityType. Chaque mode d’affichage (vue ou formulaire) est lié à un seul et unique type d’entité de contenu. Par convention, il existe des libellés utilisés pour plusieurs modes d’affichage. Par exemple, le profil standard de Drupal Core utilise le mot « Full » dans les étiquettes des modes de vue pour les types d’entités nœuds, blocs personnalisés et commentaires.

Modes de vue et affichage

Gérés globalement à l’adresse : /admin/structure/display-mode/view
Activés pour chaque bundle dans les « Paramètres d’affichage personnalisés » via des URL telles que : /admin/structure/types/manage/page/display (où « page » est un bundle d’entité node)
Configurés pour un mode de vue donné pour chaque bundle via une URL comme : /admin/structure/types/manage/page/display/teaser (où « page » est un bundle d’entité node et « teaser » est le mode de vue)

Les modes de vue comme concept existaient avant Drupal 8. Ils étaient présents dans Drupal 7. Drupal 6 disposait de la notion de « modes de construction ». Ces modes permettent aux outils de construction de sites Drupal, tels que les champs Entity Reference, de demander une entité donnée d’une certaine manière. Par exemple, supposons que « song » et « artist » sont chacun un type de nœud, et que la chanson contient un champ de référence vers artist. Le mode « full » du nœud chanson peut nécessiter d’afficher le mode « teaser » du nœud artiste. Ici, « teaser » est un mode de vue utilisé par le nœud artiste, et « full » celui utilisé par la chanson.

Typiquement, si un développeur souhaite afficher un nœud artiste en mode teaser, il configurera l’affichage spécifique à ce bundle et mode. Cela se fait via l’onglet « Gestion de l’affichage » de la page de configuration du bundle, par exemple /admin/structure/types/manage/article/display.

Sur cette page, le développeur peut activer les paramètres d’affichage personnalisés des champs (ordre, formatage) pour chaque mode de vue. Tous les modes de vue ne nécessitent pas forcément de réglages spécifiques. Par exemple, seuls les modes « RSS » et « Teaser » ont des réglages personnalisés ; les autres utilisent la configuration « par défaut ». L’association entre un bundle et un mode de vue s’appelle une vue d’affichage. @see EntityViewDisplayInterface

d8-view-modes

Modes de formulaire et opérations de formulaire

Gérés globalement à l’adresse : /admin/structure/display-mode/form
Activés pour chaque bundle via des URL telles que : /admin/structure/types/manage/page/form-display (où « page » est un bundle d’entité node)
Configurés pour un mode de formulaire donné pour un bundle via une URL comme : /admin/structure/types/manage/page/form-display/simple (où « page » est un bundle d’entité node, et « simple » un mode de formulaire)

Comme pour les modes de vue, les modes de formulaire permettent de créer différentes configurations de champs pour un même bundle. Ils autorisent plusieurs ordonnancements et réglages de widgets, alors que les modes de vue gèrent les ordonnancements et réglages de formatteurs.

Dans Drupal 7, les champs et widgets étaient configurés dans l’onglet « Gestion des champs » de chaque type de contenu. Maintenant, cette gestion est séparée en deux onglets : « Gestion des champs » et « Gestion de l’affichage du formulaire ». Cela offre plus de flexibilité quant à l’apparence des formulaires d’ajout/édition. L’onglet « Gestion de l’affichage » reste similaire à Drupal 7. En plus des types de contenu, on peut gérer les modes de vue pour d’autres entités comme utilisateurs, taxonomies, commentaires, et blocs personnalisés.

Par ailleurs, les opérations de formulaire permettent de définir quelles classes sont utilisées pour certains formulaires, comme la suppression d’un nœud. Par exemple, la classe pour supprimer un nœud est différente de celle pour l’éditer. Ces opérations sont définies dans les annotations des entités.

Voici un exemple déclarant 2 opérations personnalisées ainsi que le mode de formulaire « default » pour la même classe MyEntityForm. Assurez-vous que cette classe étend ContentEntityForm :

/**
 * @ContentEntityType(
 *   id = "myentity",
 *   handlers = {
 *     "form" = {
 *       "default" = "Drupal\myentity\Form\MyEntityForm",
 *       "add" = "Drupal\myentity\Form\MyEntityForm",
 *       "edit" = "Drupal\myentity\Form\MyEntityForm",
 *       "delete" = "Drupal\myentity\Form\MyEntityDeleteForm",
 *     },
 *   },
 * )
 */

Pour ajouter ou modifier les opérations de formulaire disponibles sur des entités existantes, vous pouvez utiliser hook_entity_type_build et hook_entity_type_alter.

Actuellement, une configuration explicite d’opération est nécessaire pour chaque mode de formulaire utilisé. Contrairement aux modes de vue, qui tombent sur la vue par défaut si une vue spécifique n’existe pas, les modes de formulaire n’utilisent pas l’opération « default » si elle n’est pas explicitement définie. Cela est considéré comme un bug. Voir #2511720 : Permettre aux modes de formulaire d’utiliser l’opération par défaut si non définie explicitement.

Pour afficher un formulaire en mode de formulaire personnalisé, utilisez _entity_form dans votre route. Par exemple, pour afficher le formulaire d’édition personnalisé de MyEntity, utilisez cette route :

entity.myentity.edit_form:
  path: '/myentity/{myentity}/edit'
  defaults:
    _entity_form: myentity.edit
    _title: 'Modifier MyEntity'
  requirements:
    _permission: 'edit myentity entities'

Un autre exemple :

Il est souvent nécessaire que les formulaires d’enregistrement utilisateur ne montrent pas tous les champs personnalisés. Après inscription, l’utilisateur accède au formulaire de modification de profil où ces champs supplémentaires sont visibles. Voici un exemple de cette configuration :

Cliquez sur « Ajouter un champ » dans /admin/config/people/account/fields
Choisissez le type « Liste (Texte) »
Donnez-lui le libellé : « Liste d’abonnement »
Cliquez sur « Enregistrer et continuer »
Remplissez la liste des valeurs autorisées, par exemple :

            1 | Nouvelles
            2 | Annonces importantes
            3 | Offres, Réductions, Promotions
            4 | Messages partenaires

Cliquez sur Enregistrer
Rendez ce champ obligatoire
Sélectionnez les quatre éléments par défaut, puis Enregistrer
Allez ensuite à l’onglet « Gestion de l’affichage du formulaire »
En bas de la liste, déployez la section « Paramètres d’affichage personnalisés »
Cochez « Utiliser des paramètres personnalisés d’affichage pour les modes de formulaire suivants » et activez « Inscription », puis Enregistrer
Une deuxième tab « Inscription » apparaît
Désactivez le champ « Liste d’abonnement » en le déplaçant dans la section « Désactivé », puis Enregistrer
Allez dans l’onglet « Gestion de l’affichage » pour vérifier que le champ « Liste d’abonnement » est bien activé

Déconnectez-vous et visitez le formulaire d’inscription. Le champ « Liste d’abonnement » ne sera pas visible.
Après connexion, ce champ sera disponible dans le formulaire de mise à jour du profil.

Types de blocs supplémentaires (EBT) – Nouvelle expérience de Layout Builder❗

❗Types de paragraphes supplémentaires (EPT) – Nouvelle expérience Paragraphes

Modes d’affichage : modes de vue et de formulaire

Menu