La gestion des images a toujours été une préoccupation clé dans Drupal. Comment fournir des pages les plus optimisées possible tout en affichant les images fournies par le contributeur et souvent bien trop grande pour l’usage final, le tout en simplifiant au maximum les opérations à effectuer par ledit contributeur ?
La génération de vignettes : un incontournable
Très tôt dans l’histoire de Drupal, un mécanisme de génération de vignettes (des versions retaillées de l’image fournies par le contributeur) est présent, principalement pour répondre au double besoin d’optimiser les éléments transmis au navigateur client, tout comme permettre une variation de tailles et de formats.
Cette brique est tellement centrale dans un site Drupal, qu’il est couramment sous-entendu que l’image “brute” fournis par le contributeur est “archivée” à jamais et ne sera plus jamais affichée, seuls ses variations/vignettes le seront, et cela, tant dans le back-office que sur le front-office.
Cette philosophie s'harmonise parfaitement avec celle d'une bibliothèque de médias ou d'une GED/DAM. L’image d’origine est une source sanctuarisée qui servira de référence pouvant être utilisée à de nombreuses reprises.
Une petite entorse peut être faite à ce concept, lorsque l’on va vouloir affiner le recadrage de la vignette. En effet, il est courant que le point d'intérêt, la zone d’attention d’une image ne soit pas spécifiquement positionnée au même endroit sur l’ensemble de notre collection d'images. C’est pour ce cas d’usage, on ne peut plus courant, que le module “CROP” et ses enfants interviennent. Ces derniers vont permettre de manière très naturelle de sélectionner la zone d'intérêt spécifique de l’image et s'insérer dans la génération de la vignette pour s’assurer que le point d'intérêt sera bien mis en avant dans la vignette.
Une cohabitation difficile
Le problème, lorsque plusieurs briques viennent s’ajouter autour d’un élément central, apportant chacune une fonctionnalité spécifique, c’est que leur cohabitation est rarement prise en compte. Et c’est le point clé ici. Le module “CROP” ne s'intéresse qu’à l’image en elle-même et ignore volontairement les usages qui en est fait. En soi, rien de particulièrement gênant ici.
D’un autre côté, la généralisation de l’usage de la bibliothèque de média a enfoui le champ d’image dans le média, loin de l’usage de l’Image (devenu média) dans le contenu. À l’usage, le contributeur a la conviction de manipuler les Images alors qu’il manipule une structure qui contient la vraie image.
C’est alors que les incompréhensions commencent. Le contributeur, habitué à pouvoir “affiner” la zone d'intérêt de son image, ne comprend pas pourquoi la bibliothèque d’Image ne lui permet plus cet affinage. Même lorsque la configuration le permet, voilà le contributeur paniqué au fait qu’en voulant choisir une zone d'intérêt dans un article en particulier, il réalise que toutes les utilisations de l’Image ont été modifiées, les différentes zones d'intérêts sélectionnées remplacées par la dernière choisie.
À quelque chose près, la situation est ainsi dans un statu quo depuis plusieurs années. Si vous avez un usage intensif des “CROP”, autant vous passer des médias. Si vous désirez centrer l’usage des images au sein de la bibliothèque de média, il faudra accepter que vous ne pourrez configurer qu’une zone d'intérêt “par défaut” pour l’ensemble des usages de votre Image.
Nos experts au service de la communauté
C’est dans ce contexte que chez Smile, l’un de nos experts a décidé d’apporter une solution et la collection de module Media Contextual Crop a été proposée. Cette collection de modules permet d’ajouter la brique manquante entre la MediaLibrary et le module “CROP”.
À l’usage, le module propose un champ de sélection des médias classiques, permettant ajouter à “CROP” la possibilité de prendre en charge de contexte d’utilisation de l’image. La collection permet ainsi, non seulement de gérer les médias gérés via des champs de référence, mais également de gérer les médias qui seraient insérés dans les éditeurs de texte riche.
En chantier depuis mars 2023, présentée discrètement à la DrupalCon de Lille, c’est au DrupalCamp de Rennes (mars 2024) que la solution a été publiquement présentée lors d’une conférence spécifique et a reçu un chaleureux accueil, montrant que le besoin existe et qu’il est depuis trop longtemps ignoré.
Une nouvelle manière de réfléchir l’usage des médias en la personnalisation des zones d'intérêts est ainsi née. Vous pourrez retrouver un enregistrement de la conférence via les réseaux sociaux de l’association Drupal France (dont Smile est également partenaire).
Envie d’aller plus loin ? Découvrez ma présentation lors du DrupalCamp !
