... de Miss Mopi bien sûr!

Tous les deux ans environ, ça me prend... J'ai envie de refaire mon site. Quoique en l'occurence, refaire n'est pas le bon terme, j'ai juste envie d'un nouveau thème, d'un nouvel habillage si vous préférez.

L'arrivée du support d'HTML5 et de CSS3 dans les dernières versions des navigateurs n'y est très certainement pas étranger, mais depuis le début de mon passage à Drupal je sais que je ne resterai pas éternellement sur ce thème.

Bon d'accord, mais qu'est-ce qui me plait? J'ai réussi à déterminer quelques traits.

• Très clairement j'aime lorsque les contenus sont bien séparés, dans des cadres par exemple mais il existe d'autres solutions.
• J'aime bien que la date soit sous forme de calendrier, ou dans un carré sur le côté. La date sous le titre je trouve ça triste.
• Alors que ma couleur préférée est le bleu, j'adore le vert pour mon site web. Ca fait plusieurs versions que je flirte avec le vert, et je n'arrive pas vraiment à en sortir.

Je me suis donc amusée à regarder les thèmes prêts à l'emploi pour Drupal 6 qui me plaisent, en voici quelques uns pour ceux qui pourraient être intéressés.

• A coffee : il gagne devant tous les autres. Et pourtant je ne l'aurais pas donné gagnant. Je n'arrive pas à déterminer ce qui me plait chez lui. Il n'a pourtant pas de séparation "physique" des divers contenus et pourtant la séparation est très claire. Son côté bicolore est bien exploité et séduisant, même si je trouve les couleurs un peu agressive.
• Delicious Fruit et son presque jumeau Blossom ont ce côté bucolique qui me séduit tant. Delicious a longtemps été mon préféré d'ailleurs.
• Les thèmes Gardening, Koi et Note Chaos sont très jolis, mais clairement trop typés...
• Plus sobres mais sympathiuques, Painted Wall, Scruffy et AD Lemon Twist.

Dans les thèmes que je vous ai présenté, je n'ai regardé ni le niveau de maintenance, ni la qualité du code. C'est juste un exercice de style pour regarder un peu ce qui se fait et ce qui me plait, puisque je compte bien programmer moi-même ce nouveau thème (et là c'est pas gagné!). Ce n'est pas pour demain!

Bon, et vous si vous deviez changer quelque chose sur le monde de Miss Mopi, ce serait quoi?

J'ai acheté le livre sur l'utilisation des modules de Drupal :

J'attends beaucoup entre autres sur les galeries photos (chapitre 7) et la création de thème (chapitre 11). Et si ça pouvait au passage m'aider à résoudre mon problème de fil d'ariane... Allez, je vous raconterai.

Bah oui depuis le temps que ça me titillait ça devait bien arriver.

But de l'opération : Passer de Dotclear et SPIP sous un système unique, Drupal. Pourquoi? Parce que! Déjà je suis bien familiarisée par ailleurs avec Drupal en version 5. J'avais envie d'étudier la V6... Quoi de mieux qu'un vrai projet pour ça ?

J'ai testé divers modules avec plus ou moins de chance :

• Migration de Dotclear vers Drupal : DC2DrupalDéfaut principal, non maintenu ni mis à jour depuis longtemps. Résultat satisfaisant nécessitant un retraitement derrière mais simplifiant quand même grandement le travail de reprise. Il a l'avantage de reprendre les commentaires. A noter : ne fonctionne que sur la version 1.
• Migration de SPIP vers Drupal : Spip to Drupal migrator A le mérite d'exister, n'importe pas les commentaires, ne conserve pas les références des éléments importés pour permettre de générer des URLs correspondantes à la version SPIP pour assurer la continuité.

Bon il est possible que je les utilise pour me faciliter une partie du travail, mais c'est pas dit...

La solution que j'ai essayé avec succès pour l'instant sur un périmètre (très) restreint, celui des auteurs de la rubrique lecture est de générer du SQL afin de créer les contenus d'après un export de la base de données.

Déjà je désire utiliser un contenu spécial pour les auteurs. Une des merveilles avec Drupal est le module CCK qui permet de créer des contenus adaptés. J'ai créer 2/3 auteurs manuellement jusqu'à ce que le contenu me convienne. J'ai fait un export SQL, étudié la structure et généré un fichier d'import avec les éléments manquants. Étant une bille en PHP par manque d'entrainement j'ai généré les requêtes en utilisant des outils bureautiques (tableur + publipostage), ce que je ne sais pas scripté, je le modifie à la main!
L'effort nécessaire à la base est surtout de comprendre comment fonctionne la base de données, et de vérifier qu'elle fonctionne après import sur des aspects comme les index de table, etc...

Concrètement pour ceux que ça intéresse :

1. Création du type de contenu, et test avec 2/3 auteurs jusqu'à satisfaction (Nom complet, nom, Prénom, n° rubrique SPIP, biographie)
2. Export des rubriques correspondantes sous forme de tableau HTML grâce à un squelette spécifique SPIP
3. Copier/Coller des éléments dans le tableur. Transformation du contenu pour s'adapter à mes nouveaux besoins/envies et posséder tous les éléments nécessaires à la réalisation de la requête (ajout du nid/vid, transformation du titre, séparation en deux colonnes du nom et du prénom, transformation de la description pour éviter les erreurs lors de l'import SQL).
4. Génération des requêtes d'après exemple (en recherchant dans la base de données l'ensemble des contenus associés à un nid/vid précis)
5. Test sur une requête d'import
6. Création d'un contenu pour vérifier que rien ne hurle ou ne s'emmêle les pinceaux
7. Test sur deux requêtes d'import
8. Import de tous les contenus restants
9. Création de la vue classées par ordre alphabétique et triées par lettre... En moins de 10 minutes avec Views, un vrai bonheur!!!

Et ça a marché : 70 auteurs migrés dans Drupal sur lesquels il n'y avait pas de commentaires (c'est vraiment la partie qui risque de s'avérer la plus enquiquinante).

Cliquez pour voir la liste générée avec le thème par défaut :

Maintenant... J'attaque les cycles chroniqués, puis les livres... Déjà, rien que définir le nouveau type de contenu va me demander un certain temps de réflexion!

Mes sources :

• Livre : Drupal 6 - Créez des sites web de qualité professionnel de David Mercer
• Drupal.org et Drupalfr

Ou réflexions d'une geekette curieuse en mal de temps...

Nota Bene : Que les choses soient claires, ce billet est un mélange de choses objectives et aussi de total feeling! Il ne se veut pas le guide ultime de la confrontation SPIP/Drupal ou DotClear/Drupal, même pas un guide du tout. Je reste persuadée que le meilleur outil est celui qu'on a envie d'utiliser.

Et moi ça fait quelque temps que j'ai envie d'utiliser Drupal. Plus je le regarde, plus je suis séduite. Au départ assez dubitative sur l'intérêt d'une telle solution, je m'attendais à me retrouver avec la même réaction que face à Joomla. Quelque chose du style "Ca c'est sympa, mais non ce n'est pas pour moi..." et en fait non c'est tout l'inverse.

Ces derniers temps mes interventions sur mon site sont rares, mais c'est général, mon activité sur le web s'est drastiquement réduite. On évolue. Mon site a déjà eu une pénurie de mise à jour avant que je passe à SPIP, parce que la création de pages statiques avait fini par me gonfler. Je pense en arriver aux même limites aujourd'hui avec SPIP/Dotclear.

Quand je veux mettre en ligne sur mon site, la première question que je me pose, c'est "dans le site ou dans le blog". Déjà c'est un frein. Ça m'a amusée, maintenant ça m'énerve. Tout mettre dans le site? Non, je n'ai pas besoin de tout formaliser. Tout mettre dans le blog, non j'ai besoin de plus de souplesse sur certaines choses.
En plus, je ne fais pas une mise en ligne sans me demander comment intégrer tel aspect ou tel autre dans un équivalent sous Drupal, bref la réflexion est amorcée malgré moi.

Je m'attends déjà à des remarques soutenant que SPIP est mieux, meilleure communauté, tout ça, tout ça. (Si si j'en ai vu sur les pages de gens qui cherchent à migrer leurs données de SPIP à Drupal...) Je connais SPIP, je sais ce qu'il vaut, ce qu'il m'a apporté, et mon envie de changer n'enlève rien à ses qualités. De même, si je ne changeais pas ça ne modifierait en rien ses défauts. Seulement... J'ai évolué, mes envies aussi, et SPIP n'a pas évolué dans le même sens que moi. Il faut savoir accepter ce genre de choses.

Donc voilà, j'aimerai un seul outil qui me permette de manière souple de choisir où je publie mes informations. J'ai déjà eu des remarques dans mes commentaires du style "Oui mais SPIP peut faire du blog!". Oui. Mais SPIP n'est pas un blog. Faire du blog avec SPIP m'agacera je le sais. Il est trop contraint dans son formalisme webzine pour me plaire là-dessus.
En plus, c'est peut-être tout simplement (enfin simplement...) toute l'organisation, le concept de mon site qui est à revoir. Les technologies et les usages ont évolués, et je suis sure que je pourrais en tirer bénéfice. Réintégrer tout dans SPIP ne changera rien à ce qu'il est actuellement.

Attention, Drupal n'est pas parfait. Je perçois déjà certaines choses que j'ai faites très simplement dans SPIP qui vont être plus ardues sous Drupal. Je suis aussi consciente qu'une "erreur" de conception dans SPIP est plus simple à rattraper que dans Drupal, 90% se passant dans le thème de SPIP, revenir en arrière peut être plus simple. Dans Drupal ça concernera plus souvent les données qu'il me faudra réinjecter sous une autre forme...

Et puis par moment, je trouve que SPIP est trop... Comment dire? SPIP?
Le langage ressemblant au wiki mais pas vraiment le même qui fait que je me plante une fois sur 2 vu que je saisis de plus en plus d'informations au format wiki... La sauvegarde/restauration de la base de données qu'on ne peut faire QUE par l'interface SPIP avec perte des statistiques au passage sinon ça ne fonctionne pas (ou du moins pas toujours). Cette interface privée que je ne peux pas personnaliser sans quitter les rails de la distribution standard - donc forcément pas maintenable...
Et pourtant, sur d'autres sites que je gère, je ne me vois pas les faire quitter SPIP pour autant.

SPIP 2.0 arrive. Je ne suis pas sûre d'avoir envie de m'investir dans cette version pour mon site. Tant qu'à tout repenser, j'ai plus envie de regarder un nouvel outil qui me tente...

Bon d'accord, c'est aussi la curiosité maladive d'une geekette à l'affut de tout ce qui se passe sur le web et en perpétuel mouvement!

Me manque plus que l'outil de migration...

Première et petite expérience concrète d'un site sous Drupal!

Besoin

Disposer d'un outil en ligne permettant la tenue à plusieurs d'un agenda privé - mais commun à tous les membres.

Identification des modules

28 modules sont répertoriés dans la catégorie Event

Les deux modules que j'ai identifié sont Event pour la gestion d'un contenu de type événement et Calendar pour l'affichage sous forme de calendrier.

Installation de Drupal

Je prends la version en cours du moment, la 5.6 (passée à la 5.7 depuis). Je l'installe, et j'obtiens un message d'erreur sur un paramètre (register_globals) qui serait actif et il faut donc modifier le paramètre. Après quelques recherches et quelques tentatives dans .htaccess conformément à l'aide trouvée dans la communauté Drupal, la 5.6 refuse toujours de s'installer à cause de ce paramètre.

Après analyse, il semble que les personnes ayant migré de la 5.5 à la 5.6 voient ce message d'erreur dans la partie admin mais que cela n'empêche pas Drupal de fonctionner. Les nombreuses questions à ce sujet ont pour réponse que cela vient d'une mauvaise configuration PHP et absolument pas de Drupal lui-même, ce qui m'a - je dois dire - légèrement agacée!
Le problème se répète trèèèèèèèèèès souvent, et chez de très nombreux hébergeurs. En conséquence, même si cela vient d'une mauvaise configuration chez eux, on ne peut pas prétendre les obliger à changer leur configuration pour un site en mutualisé... Cela fonctionnait avant, cela ne fonctionne plus, pour moi c'est une régression! Je veux bien un message d'erreur mais pas un blocage.

Correction trouvée? J'ai installé la 5.5 et ferai les mises à jours plus tard.

Installation des modules

C'est là où je comprends que les modules ne sont pas, mais alors pas, mais alors pas du tout autonomes... Après l'installation de Event et Calendar, me voilà partie à la pêche de Views, Date API, puis après ces modules de CCK! Pour m'apercevoir au final qu'Event inclut son propre calendrier suffisant pour mon besoin.

Paramétrages

Tous les paramétrages ci-dessous se passent dans les pages d'administration. Je n'ai aucune modification à apporter aux fichiers du site.

• Je crée les utilisateurs hors administrateur. Dans les droits je les autorise à créer des événements, à les modifier, à changer le thème, et voir le contenu - ou plus exactement je supprime la capacité des anonymes à voir le contenu du site.
• J'édite les liens primaires en ajoutant un lien vers le calendrier, un lien vers la création d'évènement, et un lien vers la page des derniers contenus.
• Je modifie le titre du site, et le contenu de la page d'accueil pour afficher directement le calendrier.
• Et enfin j'installe quelques thèmes histoire de voir... (le thème de l'impression d'écran est Dreamy).

Le dernier problème rencontré concerne les thèmes. Ils ne semblent pas tous fonctionner en standard. Certains n'affichent pas les liens primaires **gasp**, d'autres affichent des messages d'erreurs à toutes les pages... Bref tous ne sont pas totalement au point!

Conclusion

Il semble que j'aurai pu me contenter du module Event et du module Views, mais je n'ai pas vérifié si le site criait quand je désactivais les autres modules (Calendar, Date, CCK). Je n'ai pas encore non plus regardé la francisation du module, tout le site est en anglais.

Temps de mise en ligne : entre une heure et une heure trente (recherche du pb d'installation compris).
Temps de prise en main d'un utilisateur confirmé d'internet mais novice de Drupal : instantané.

Il me reste bien sûr des choses à améliorer. Mais sincèrement 80% de mon besoin est là, tout en laissant la place à l'intégration de nouvelles fonctionnalités si besoin.

Le module Image peut être trouvé ici : Image: image nodes, attached images, and galleries - drupal.org

Pour l'installation, voir le billet sur le sujet

Les différentes fonctionnalités activables dans le module sont :

• Image : Permet le chargement, redimensionnement et l'affichage d'images.
  • Image Attach : Permet facilement d'attacher des noeuds images aux autres types de contenu
  • Image Gallery : Permet le classement et l'affichage des images basées sur les catégories
  • Image Import : Permet d'importer des images par lot à partir d'un répertoire sur le serveur.
• ImageMagick Advanced Options : Ajoute des fonctionnalités à ImageMagick.

Le reste du billet décrit plus précisément ces fonctions.

Image

La première fonction peut être configuré sur les points suivants : le répertoire de stockage par défaut, le poids maximum autorisé pour une image, la taille de l'image lorsqu'elle est présentée en mode normal, en vignette et en prévisualisation, ainsi que pour chacun de ces cas si on ouvre le résultat dans la même fenêtre ou dans une nouvelle fenêtre.
Après activation, elle donne accès à un nouveau type de contenu "Image". Avec un titre, une description et bien sûr l'image en elle même. On y retrouve également les options par défauts activées dans Drupal (fichiers attachés - oui ça fait bizarre -, les options de publication, paramètre du menu, paramètres des commentaires, ...

Image Gallery

On peut utiliser les catégories pour classer les images. Cependant, à part classer les images ça n'a pas énormément d'impact, dans le sens où on n'obtient pas de galerie, juste une navigation transverse limitée. Pour des galeries, il faut activer la fonction Image Gallery. Bien que cette fonction soit basée sur le module de Taxonomy, les éventuelles catégories et termes créés pour les images ne sont pas compatible avec ce module. Donc il vaut mieux partir directement sur l'utilisation du module Image Gallery.
Il fonctionne de la même manière que les catégories, mais l'affichage permet la juxtaposition des vignettes, plutôt que de gros blocs les uns en dessous des autres, ainsi que la pagination. Le côté désagréable est l'impression de fouillis si les images de sont pas de même hauteur. Note pour plus tard : si possible mettre les images dans un div de largeur et de hauteur fixe, basé sur la taille des vignettes.

Les images utilisées dans cet exemple sont des logos des jeux Final Fantasy.

Image Attach

Cette fonction s'active en deux temps : tout d'abord le module (Administrer >> Construction du site >> Module), puis il faut ensuite éditer les contenus pour lesquels on désire autoriser l'association (Administrer >> Gestion du contenu >> Types de contenu). A partir de ce moment là, on voit apparaitre une nouvelle section dans le contenu qui permet soit de lier une image existante, soit de mettre en place une nouvelle image qui apparaitra alors comme vignette associée au contenu.

Image Import

A l'activation du module, le site signale que le répertoire d'import n'existe pas. Un changement de nom du répertoire temp qui n'a pas été généralisé? Il suffit de créer le répertoire import dans le dossier monsite/files/images/.

Il faut aller ensuite dans Administrer >> Gestion du contenu >> Image Import pour accéder aux images que vous auriez déposer là par FTP par exemple afin de les enregistrer automatiquement comme de nouveaux contenus "Image". Il a fallu que j'édite et enregistre la configuration du module (Admistrer >> Configuration du contenu >> Image Import) pour que le module fonctionne.

Dans la page d'import vous pouvez pratiquement tout configurer : le titre, la description (ou corps), et la galerie à laquelle rattacher l'image. Le system se charge des créer alors les contenus et de déplacer les images.

ImageMagick Advanced Options

Donne accès dans la configuration du site à une page Boite à outils image qui permet de régler la compression par défaut des jpg.

Voulant voir comment gérer une galerie d'image, je me suis tournée vers le module "Image". Il s'agit donc de regarder comment installer et paramétrer un nouveau module pour Drupal. La page d'aide sur le sujet que j'ai trouvée est sur le site de Drupal.org : Adding Modules and Themes.

La première chose à faire est de créer le répertoire qui accueillera les modules. Pour éviter de les mélanger avec les modules du coeur de Drupal et faciliter la maintenance du site, il faut aller dans monsite/sites/all/ et créer un répertoire modules. On peut d'ailleurs au passage créer le répertoire themes pour le moment où on en aura besoin. J'avoue que je m'interroge - sans avoir chercher la réponse - sur la raison pour laquelle ces répertoires n'existent pas par défaut. Bref, ce n'est pas très important.

Il faut décompresser le contenu de l'archive qui contient généralement un répertoire appelé nom-du-module qui devra être téléchargé vers le serveur dans le répertoire modules créé ci-dessus. Il sera automatiquement détecté par Drupal.

Par défaut le module est installé en anglais, même si votre site est paramétré dans une autre langue par défaut. Il faut alors installer la traduction du module. Cette traduction est disponible dans le dossier "po" du module (donc dans monsite/sites/all/modules/nom_module/po/) et est intitulé fr.po dans le cas de la langue française. Pour installer cette traduction, il suffit de suivre la procédure pour traduire Drupal déjà abordée ici en allant chercher le fichier de localisation.

Ensuite les modules s'activent et se désactivent dans l'administration (Administrer>>Construction du site>>Modules) dans une nouvelle section indépendante des sections par défaut de Drupal (qui sont Core - facultatif et Core - obligatoire).

Lorsque les différentes fonctions du module sont activées, de nouvelles sections apparaissent dans Administrer>>Gestion du contenu et Administrer>>Configuration du site. Ce qui me fait peur c'est de voir que l'activation du module a ajouté par exemple trois entrées dans Configuration du site, je n'ose imaginer le foutoir de l'administration au fur et à mesure de l'ajout de nouvelles fonctionnalités!

Drupal VS Spip : Round 1

Spip versus Drupal côté gestion de contenu et gestion de site

SPIP vs Drupal (ou les différents types de CMS) - Le Monde des CMS - Forum - ixprim-cms.org - Système de Gestion de contenu - CMS

La plupart des CMS (Content Management System, ou système de gestion de contenu) proposent des systèmes de catégorisation (les catégories pour DotClear, les groupes de mots-clés/mots clés sous SPIP). On peut retrouver également ce genre de concept dans les "tags" et les nuages de tags qu'on voit fleurir un peu partout. Bref le principe de cette notion est de pouvoir faciliter l'accès à l'information en fonction d'une thématique donnée, de faciliter la navigation transverse entre les informations (je cherche une télé, je peux remonter à la catégorie images et sons et me retrouver sur les DVDs ou à partir de la fiche télé accéder à l'ensemble du matériel proposé par ce fabricant, ou dans la même gamme de prix, ...)

Drupal n'échappe pas à la règle.

C'est le module Taxonomy qui s'en charge, et je ne sais pas si ça vient de la traduction, mais les explications font un peu fouilli. On parle de catégorie, puis de vocabulaire, puis de terme. Je pense que ça correspond à une vraie réflexion portée également par ce qu'on retrouve dans les nuages de tags : le but est d'associer au contenu des mots permettant d'identifier rapidement de quoi ça parle en liant d'ailleurs un mot à d'autres mots proches dans le sens ou l'utilisation. On est un peu au delà de la simple notion de mots-clés.

Concrètement le terme est le niveau de plus bas, c'est lui que l'on associe au contenu (télévision, de 99 à 199€, DVD, MarqueXXX). Ces termes sont rattachés à des vocabulaires (Images et sons, catégories de prix, Marques). Et c'est tout ce concept qui s'appelle des catégories.

L'exemple du site français sur Drupal n'est pas très judicieux : ils créent un vocabulaire appelé "Catégorie" ce qui perturbe plus qu'autre chose quand on essaye de comprendre face à l'interface.

Un plus qui est dû au fonctionnement intrinsèque de Drupal est la possibilité de choisir sur quels type de contenus on peut associer les catégories (l'ajout de nouveaux contenus par module met automatiquement la liste à jour), la possibilité de renseigner des termes connexes (on rentre enfin dans la notion de vocabulaire?), et probablement d'autres choses encore non expérimentées.
Enfin, un autre gros avantage : on peut dans un vocabulaire classer les termes en arbre! Par exemple : Animaux domestiques est un vocabulaire, Félins et Canins les termes de premier niveau, Chat et Tigre de deuxième niveau ET rattaché à Félin, Chien également de deuxième niveau mais lui rattaché à Canin, etc...

Le fonctionnement de base de Drupal est basé sur les modules. Chaque module est un ensemble de fichiers, apportant de nouvelles fonctionnalités, et pouvant interagir avec d'autres modules (qu'ils soient proposés par défaut à l'installation de Drupal ou ajoutés en fonction du besoin).

Un certain nombre de ces modules sont le cœur du système, ce qu'on appelle le core, et assurent le fonctionnement de base de l'application. Les autres sont totalement optionnels mais font toute la puissance de Drupal.

Les modules du core sont :

• Block : ce qui définit les boites en haut, à gauche, à droite, au milieu, bref, il s'agit d'une des composantes modulaires de l'interface, qui permet de rajouter une boite contenant de nouvelles fonctions. A étudier : faut-il ou pas modifier les fichiers du thème pour faire apparaitre des liens dans les blocs ou est-ce de la responsabilité des modules d'y mettre les liens sans toucher le code?
• Filter : hum, a priori c'est le module qui gère les notions de publié/non publié, et l'affichage en fonction des droits.
• Node : le module Node semble gérer les contenus de base (node) que l'on peut ensuite typer (comme les articles/stories ou les pages, ce sont tous les deux des nodes mais pouvant avoir des comportement différents).
• System : gère la zone d'administration
• User : gestion des utilisateurs, inscription, authentification...
• Watchdog : Journalisation des évènements.

L'ensemble de ces éléments définissent le coeur minimal de Drupal. Même si d'autres modules sont activés par défaut, seuls ceux du core sont indispensables.

Les autres modules activés par défaut :

• Color : offre un système de modification de couleur de certains thèmes
• Comment : gestion des commentaires sur les contenus.
• Help : l'aide utilisateur
• Menu : permet la personnalisation des menus par l'administrateur (A étudier : le contenu, la forme, la position?)
• Taxonomy : système de classification / Catégorisation du contenu

Autres modules indispensables ou intéressants :

• Locale : permet de gérer la traduction de l'interface de Drupal.
• Forum : Mise en place d'un forum géré par Drupal et s'appuyant sur les modules Comment et Taxonomy.

Après il y a des choses comme un aggrégateur de fils RSS, des formulaires de contact, des blogs utilisateurs, un système de recherche, de suivi des nouveautés, de statistics, ...

L'activation de ces modules dans l'interface d'administration provoque immédiatement un affichage de ces éléments sans même avoir à toucher le code de quoi que ce soit. C'est un plus, cela signifie qu'on peut débuter un site avec Drupal sans devoir mettre immédiatement les mains dans le cambouis.

Le seul truc que je n'ai pas encore compris, c'est par exemple l'intérêt du module Blog par rapport à un contenu standard. Je suppose que le module doit gérer un affichage et des droits particulier pour ce format.