Deuxième volet de ma mini-série sur la gestion des images dans Drupal : je voudrais revenir plus longuement sur la constitution d'albums, qu'on appelle aussi galeries, mais c'est un anglicisme (surtout quand on y colle deux L). Comme pour mon billet sur les images, je ne cherche pas à dresser un catalogue exhaustif des solutions possibles mais juste à synthétiser les différentes logiques qui peuvent se mettre en oeuvre.

Car comme toujours avec Drupal, on peut aborder cette question de différentes manières. S'agissant des albums, LA question primordiale consiste à distinguer si vous voulez des albums statiques ou des albums dynamiques. Pour le dire autrement : souhaitez-vous que des utilisateurs puissent ajouter facilement des images à un album (ce que j'appelle dynamique) ou bien qu'un album soit constitué une fois pour toute sans qu'il soit possible ou nécessaire d'y ajouter ou d'en retrancher des images (ce que j'appelle statique).

Dans l'un et l'autre cas, il faudra également se poser quelques autres questions :

• l'ordre dans lequel on veut afficher les images dans un album donné : veut-on pouvoir le contrôler ou pas ?
• la facilité d'usage pour les utilisateurs (pour ajouter des albums et pour associer des images aux albums)
• la gestion des permissions sur les albums : qui pourra créer des albums, qui pourra modifier la composition des albums existants ?

On peut concevoir un album dans Drupal de deux manières différentes : comme un regroupement de champs ou comme un regroupement de noeuds. Dans le premier cas, l'album sera un noeud en tant que tel, et dans le second cas il sera assimilable à une catégorie. Aucune de ces solutions n'est meilleure que l'autre dans l'absolu, le choix dépendra uniquement de la situation dans laquelle vous vous trouvez. A vous de savoir si vous devez gérer vos albums comme des objets fixes et primaires (des contenus statiques) ou si vous voulez que leur composition soit facilement évolutive. La première option sera globalement plus simple à mettre en oeuvre, et la seconde sera plus souple, mais vous donnera moins de contrôle sur les albums eux-mêmes.

Notez bien que j'écarte ici complètement la question de l'affichage (comment faire un diaporama, etc.).

L'album comme noeud

Vous pouvez créer un type de contenu Album photos ou Galerie d'images avec un (voire plusieurs) champ Imagefield, auquel vous fixerez ou pas un nombre de valeurs limite. Pour alimenter un album (en images), il faudra "rentrer dedans" (le créer puis l'éditer). Le module Gallery Assist correspond à cette logique, et fournit tout ce qu'il faut mais n'utilise pas Imagefield (apparemment, il utilise comme Biblio son propre système de champs images).

Question : un seul champ à valeurs multiples ou plusieurs champs à valeur unique ?
Réponse : ça dépend ! ça dépend si vous voulez contrôler l'affichage des images (dans ce cas : plusieurs champs à valeur unique), ou si vous voulez un nombre déterminé d'images, a minima OU a maxima OU a minima ET a maxima (si vous voulez impérativement 4 images, pas une de plus et pas une de moins, il faut 4 champs obligatoires à valeur unique), etc. Rien ne vous empêche du reste de combiner des champs à valeur unique ou à valeurs multiples, limitées ou pas. La seule chose que vous ne puissiez pas faire, c'est un nombre de champs illimité.

Cette approche "album comme noeud" est pertinente si :

• vous avez besoin d'autres champs associés à l'album, par exemple un texte qui l'introduit ou même simplement un auteur de l'album
• vous souhaitez donner à vos albums un template spécifique : vous pourrez créer un node-album.tpl.php et vous amuser avec ;
• vous voulez contrôler facilement quels utilisateurs peuvent créer ou modifier les albums : vous aurez alors des permissions create Album content, edit any/own Album content... ;
• les images n'ont pas besoin d'être utilisées dans plusieurs albums ;
• vous avez besoin de contrôler totalement l'ordre dans lequel les images apparaîtront (par drag'n'drop des champs dans le type de contenu ou des valeurs d'un champ dans le noeud)
• vous voulez utiliser sur les albums une API annexe : les commenter, les noter (Voting API), les marquer (Flag), les utiliser en conjonction avec Organic Groups pour faire des albums de groupe, contrôler l'accès par type de contenu, etc. Ou même simplement les classer en catégories ou les référencer dans un autre type de contenu.

A priori (mais avec Drupal il vaut mieux ne pas avoir trop d'a priori), c'est la solution la plus simple pour faire (ou faire faire) beaucoup de petits albums si vous n'avez pas besoin de gérer les images individuellement. Mais la modification d'un album (ajouter une image, en retirer une autre) est peut-être un peu complexe, avec un risque de mauvaise manipulation (vous pouvez versionner le contenu, remarquez...). Ce n'est pas une solution très pratique si vous faites un album thématique alimenté "en continu" : c'est plus adapté à des albums "événementiels", alimentés une fois pour toutes et rarement modifiés.

Si vous traitez les images elles-mêmes en noeuds, comme je l'ai exposé précédemment, alors vos albums seront des regroupements de noeuds. Cette deuxième solution a aussi ses avantages, et notamment la possibilité d'associer une image à plusieurs albums.

L'album comme association de noeuds

Concrètement, vous disposez ici de toutes les possibilités de Drupal pour regrouper des noeuds d'un même type de contenu, à commencer par la taxonomie que l'on peut employer de diverses manières : un vocabulaire albums avec autant de termes que nécessaire (c'est la façon dont fonctionne le module Image Gallery), ou même plusieurs vocabulaires associés au type de contenu Image. Il faudra mettre en "tags" un vocabulaire si vous laissez tous les utilisateurs créer des albums et/ou donner des droits sur la taxonomie à des utilisateurs de confiance (c'est le moment de découvrir Taxonomy Delegate).

Si vous utilisez la taxonomie, pensez à l'hypothèse où un utilisateur souhaite créer un album avec des images déjà créées, ce qui implique d'éditer les images : il faudra lui donner la permission nécessaire, et recourrir éventuellement à Views Bulk Operations. Pour éviter les inconvénients de cette situation, vous pouvez opter pour un module de marquage (comme Flag) qui ne nécessite pas d'éditer les images. Nodequeue fait à peu près la même chose que Flag mais permet d'ordonner les noeuds (par drag'n'drop) dans la file ou de gérer les permissions différemment. Ils ne sont pas conçus comme modules d'albums mais pensez-y. Ils vous permettront par exemple de donner à des utilisateurs la permission de gérer chacun tel ou tel album, ou de constituer leurs propres albums.

Vous construirez l'album avec le module Views. Au sens propre, l'album lui-même n'existera pas : il ne sera qu'un affichage, pas un objet. Avec les conséquences que cela implique sur la gestion des permissions ou l'utilisation de l'album par d'autres API (on pourra commenter les images une par une mais pas les albums, par exemple).

Vous comprenez par ailleurs que l'alimentation de l'album se fera "extérieurement" à l'album. La logique est inverse à celle de l'approche précédente : au lieu de créer un album et d'y associer des images, on crée une image et on lui associe un ou des albums.

Cette solution est pertinente si :

• vous souhaitez que les albums soient alimentés régulièrement
• vous avez un petit nombre d'albums créés et gérés par un petit nombre d'utilisateurs ou vous n'avez pas besoin d'une administration rigoureuse des albums (les tags = ça part dans tous les sens)
• ça ne dérange pas vos utilisateurs que leurs images apparaissent éventuellement dans des albums créés par d'autres (eh oui ! pensez-y !)
• vos utilisateurs comprennent la logique "une image peut être associée à plusieurs albums" (ça n'a l'air de rien, mais ce peut être très déstabilisant - d'ailleurs vous-même, ça ne vous a pas déstabilisé, la taxonomie de Drupal ?)
• chez vous les images sont des noeuds, ce qui vous permet de les commenter, les noter, ou de contrôler leur accès (via un Taxonomy Access Control par exemple) dans l'hypothèse où certaines seraient réservées à un public précis.

Le noeud, qui regroupe des noeuds

Supposons maintenant que vous souhaitiez utiliser tout le fun disponible autour des noeuds (permissions, commentaires, theming, vote, etc...) à la fois sur les albums ET sur les images ; eh bien oui, c'est possible ! En concevant les albums comme des noeuds qui en regroupent d'autres : Drupal sait faire ça aussi.

Pensez par exemple au Node Reference (eh oui, on y revient toujours !) : un type de contenu Album avec des références à des contenus de type Image, et en voiture Simone ! Faites un essai avec Image Attach ou bien construisez votre propre système (ne pas oublier de gérer l'affichage du champ Référence_à_un_contenu_Image)... Je vous laisse tester Node Gallery qui paraît correspondre à cette approche.

On peut aussi imaginer un type de contenu qui emballe une vue (View Reference ou, clé-en-main, Views Gallery). C'est-à-dire que vous donnez une existence concrète à la vue. J'ai parlé plus haut de Nodequeue : sauf erreur de ma part il existe un module dérivé qui permet de constituer un noeud à partir d'une file (Nodequeue Node je crois).

Vous remarquerez que conceptuellement, la première option équivaut à celle de l'approche "album comme regroupement de champs" (sauf qu'il s'agit de références et non plus directement d'images), et la seconde à celle de l'approche "album comme regroupements de noeuds" : on retrouve la distinction entre les deux types d'alimentation de l'album, soit en "rentrant dedans", soit "par l'extérieur".

Et les plateformes externes ?

Si vos images ne sont pas gérées par Drupal, mais hébergées sur une plateforme tierce comme Picasa ou Flickr, il existe des modules spécifiques pour créer des albums à partir de ces plateformes. A vous d'explorer les possibilités qu'ils vous offrent. En général un module implémente une API. Solution pratique si l'hébergement est limité et que vous combinez votre site Drupal avec un compte Flickr par exemple, mais qui le sera beaucoup moins si vous devez multiplier les modules parce que vos utilisateurs mettent leurs images, les uns chez Google, les autres chez Yahoo.

Vous pouvez donc recourir au module Embedded Media Field, signalé par Jean-Cédric T. en commentaire de mon billet sur les images, et de différentes manières :

• créer un type de contenu Album avec un champ Embedded Media File (éventuellement multi-valué)
• créer un type de contenu Album avec un champ Imagefield et un champ EMF pour mélanger dans un même album des images venues d'ailleurs et des images hébergées sur votre site.
• créer deux type de contenus distincts, un Image avec un champ Imagefield uni-valué et un Image embarquée avec un champ EMF uni-valué ; vous pourrez ensuite créer des albums mixtes (ou pas) au moyen de l'une ou l'autre techniques de regroupements de noeuds détaillées plus haut.

L'idée est de retrouver une gestion (homogène) des images par Drupal, ce qui nous ramène au problème précédent. En réalité vous ne gérerez pas des images, mais des références à des images. Attention toutefois à ne pas construire une usine à gaz en reproduisant de façon compliquée ce que les webservices populaires offrent "user-friendly"...

Pour conclure

Pour résumer, je pense que la première approche convient mieux si vous prévoyez de nombreux albums créés par une importante communauté d'utilisateurs, et des albums contenant relativement peu d'images et qui ne seront pas modifiés souvent dans leur composition. La seconde correspondra plutôt au cas où vous souhaitez quelques albums thématiques capable de recevoir facilement de nombreuses images ajoutées petit à petit. Un cas pratique pourrait être la gestion de son book par un artiste. Remarquez que dans les deux cas, la création d'albums contenant des images déjà présentes sur le site sera relativement problématique : il faudra soit recharger ces images, soit éditer les noeuds correspondants.

Par ailleurs on gagne toujours à modéliser son site Drupal en noeuds, car les noeuds se manipulent facilement : ils se classent, se commentent, se référencent, se notent, etc. Mais une granularité trop fine se paie en complexité : un noeud doit être créé individuellement tandis qu'une vue s'alimente toute seule. Anticipez le problème des opérations en masse, notamment si vos utilisateurs veulent télécharger (ou importer depuis Flickr) plusieurs images facilement.

Une dernière précaution, habituelle : quelle que soit la solution que vous reteniez, préoccupez-vous de sa pérennité dans la modélisation et l'éco-système du développement Drupal.

Bonus-double-action

Le module Gallery API distingue la création des albums et leur affichage, et permet de créer des albums soit par champs CCK soit par vues de noeuds. C'est une approche assez intéressante. Je ne l'ai toutefois jamais utilisé.

Bonus numéro 2 (hors-sujet-quoique-pas-complètement) : une ressource signalée par Robin sur Twitter à propos du module Media : Media Mania - The Multimedia solution for Drupal 7.