Spécifier pour Drupal : content types / assets

Types de contenu & champs Drupal

Dans Drupal, un type de contenu correspond à :

• un formulaire en back office ;
• un template en front office (en général).

Un type de contenu possède :

• un ensemble de champs typés ;
• un ensemble de styles d'affichage (appelés view modes)

Lorsque l'on spécifie pour Drupal, il est conseillé de se référer aux types de champ Drupal afin de limiter le travail de rapprochement entre votre façon de décrire le format du champ et celui existant dans l'outil.

Une liste pourra par exemple avoir un format :

• List (float),
• List (integer),
• List (text).

Et on distingue les formats de texte suivant :

• Long text,
• Long text and summary,
• Text.

Les types de champs ne sont pas limités. Une installation standard de Drupal fourni une base qui peut être complétée par des modules spécifiques (link, node reference...) ou au travers de l'installation de module généraux (date, par exemple, fourni des champs typés tels que date, all day, repeat...). D'où l'importance de toujours spécifier pour Drupal... avec une instance de test sous la main :-)

Les principaux champs disponibles sont :

• Boolean,
• Decimal,
• Integer,
• Float,
• Long Text,
• Long Text and summary,
• Text,
• File,
• List (float, integer, text),
• Link,
• Image,
• Video (embeded),
• Date (ISO, Unix Timestamp),
• Entity (list, collection, reference),
• Node reference,
• Term reference,
• User reference,
• Field collection,
• ...

Field collection

Il arrive souvent que l'on veuille créer un champ... contenant plusieurs champs. Hors ce type de champ n'existe pas en standard dans Drupal.

Deux solutions existent :

• créer un nouveau type de champ au travers d'un module ;
• utiliser le module field_collection.

Ce dernier permet d'ajouter à son type de contenu un champ de type field collection. A partir de là, le champ ajouté peut lui même contenir autant de champs que nécessaire. C'est vraiment pratique et, surtout, cela apporte une réponse générique à un besoin récurent.

A ne pas oublier quand on spécifie !

Différencier les types de contenu

Tous les contenus d'un projet ne sont pas égaux. Pour les distinguer, on peut s'appuyer sur leur statut éditorial et la manière dont ils sont utilisés dans le site.

Statut éditorial :

• "vrais" contenus = un template et/ou un workflow lui sont dédiés (cas de l'article par exemple);
• contenus "faibles" = jamais affichés seuls (cas d'une bio par exemple)

Réutilisation :

• affiché une seule fois à un endroit précis (cas de l'article par exemple) ;
• utilisé un peu partout dans le site (cas d'une bio ou une pub par exemple).

Cette analyse est fondamentale car elle permet de typer éditorialement les contenus du projet pour ensuite les spécifier avec les bonnes entités Drupal.

Content types

Les types de contenu Drupal sont utilisés pour les principaux contenus du projet : articles, dossiers... On peut facilement leur appliquer un workflow, les traduire, etc. en s'appuyant sur des modules contribués par la communauté Drupal (Internationalization, Workflow...). Ils peuvent se contenir eux-même. Par exemple, un type de contenu dossier peut référencer un type de contenu article.

Assets

Les assets sont des entités proches du type de contenu. Mais on les utilise pour des contenus qui n'ont, a priori, pas de vie propre (cas d'une bio ou une pub par exemple) et qui sont utilisés à plusieurs endroits dans le site (image par exemple). Les assets sont gérés par le module Asset. Ils sont facilement insérables dans le corps des contenus via CKEditor. Cependant, les assets ne sont pas supportés par les principaux modules "clé en main" de workflow (Workflow) et de traduction (Internationalization).

Spécifier les types de contenu

Une fois la ventilation entre les différentes entités Drupal réalisée, on peut passer à la spécification des types de contenu. Le modèle que nous utilisons depuis début 2007 n'a pas changé. Il a été éprouvé sur tous types de projets : internationaux, multi-lingue, multi-marché, multi-tout-ce-qu'on-veut, e-commerce, éditorial, moins de 50 KE, plus de 300 KE...

Le modèle

Label

C'est le nom affiché pour les humains (human readable name). Il est affiché en back office mais peut aussi l'être en front office (cas des formulaires, des fiches en tous genres...). Peut être modifié à n'importe quel moment.

Nom machine

Ce nom est très important car il n'est pas modifiable et il est repris partout. Changer ce nom en cours de route revient à détricoter les templates, les vues... Il faut donc le choisir avec précision ou laisser les développeurs se débrouiller avec.

Quelques bonnes pratiques :

• Préciser les champs qui sont partagés par plusieurs entités (ils ne seront pas préfixés),
• Préfixer les champs spécifiques à une entité (par exemple, pour un champ accroche utilisé uniquement dans le type de contenu article, on utilisera field_article_catchline plutôt que field_catchline),
• Jouer avec les "s" (field_tags implique qu'il y a plusieurs tags alors que field_date implique qu'il n'y a qu'une date).

Type

Cette colonne doit comporter au minimum 2 informations essentielles :

• le type de champ (voir le début de l'article),
• le widget utilisé.

Le type de champ n'est pas modifiable. Il faut donc le choisir avec soin. Hors ce n'est pas toujours aussi simple qu'il n'y paraît. Le choix entre une liste d'options (List (text)) et une référence à un vocabulaire (term reference)... anime souvent des débats houleux, surtout dans le cas des sites multi-lingue. Nous rediscuterons de ces subtilités dans un autre article dédié aux taxonomies.

Le widget, lui, est modifiable à n'importe quel moment.

Specifications

Cette colonne permet de préciser toutes sortes de comportements, contraintes, etc.

C'est là, par exemple, que l'on précise les contraintes d'un champ image :

• Nombre d'items,
• Type d'image (png with transparency par exemple),
• Taille minimale en pixels,
• ALT (par exemple ALT = [article:title]).

Ou que l'on précise le comportement de champs conditionnels :

Displayed if [article_type] == "News"

Dans le cas d'un champ référencant d'autres entités, on peut aussi préciser :

• Quelles entités doivent être listées (par exemple List only articles with the same language as the node being edited && where [article_type] == "News")
• Le type de dialog disponible (par exemple Reference dialog: add, edit, search.)

Et ainsi de suite.

Allez, maintenant, c'est à vous !

Ressources

• Le lien officiel (en anglais),
• About content types (en anglais),
• Comparison of Asset Management modules (en anglais),
• Lien direct vers la page du module "Asset" (en anglais).