Ajouter des icônes de fichier pour le module Filebrowser

14/04/2009 : Avec la version 2.0 rc7 du module, celui-ci est livré avec un jeu d’icône et le code à changé, la convention de nommage étant désormais : fb-FILETYPE-icon.png par exemple fb-JPG-icon.png

Le module filebrowser créé un type de contenu permettant de lister le contenu d’un répertoire.

Ce n’est écrit nulle part, mais en jetant un oeil au code du module je me suis rendu compte qu’il prenait en charge l’affectation d’icônes pour les dossiers et les types de fichiers.

Il vous suffit de créer un répertoire /icons/ dans modules/filebrowser et ensuite de placer vos icônes png dans le dossier en respectant la convention de nommage suivante :

file-ext.png ou «ext»est remplacé par l’extension de fichier pour laquelle vous voulez avoir une icône. Pour le répertoire, simple c’est file-folder.png.

Les modules de Chat

Les modules de chat

Un Chat offre les caractéristiques d’une conversation écrite à l’identique de celle des messageries instantanées. Il permet une communication immédiate à plusieurs et peut être considéré comme un forum instantané pour les messages courts. Par contre les messages ne sont normalement pas conservés.

Classiquement, le Chat a deux utilisations, publique ou privé. Public, le Chat sert à converser entre membres d’un site. Privé, la conversation est limitée à un groupe d’utilisateurs ou d’administrateurs. Cette dernière utilisation convient particulièrement à l’enseignement en ligne, la gestion de projet…

Avec le développement des messageries incluant la visiophonie, le Chat peut sembler désuet, mais il conserve plusieurs avantages. Le message écrit est plus lent à rédiger, et donc impose une pus longue période de réflexion entre chaque échange. La conversation écrite conserve son efficacité même si le nombre de participants augmente, alors que la conversation orale tourne à la cacophonie. C’est donc pourquoi le Chat continue d’être utiliser dans des sites collaboratifs. Le choix de l’installation d’un Chat depend donc de son contexte d’utilisation, mais aussi de la disponibilité des autres solutions de communication : forum, messagerie extérieure ou interne, courriel.

Les modules de Chat s’évaluent principalement en fonction de :
- L”usage minimal de la bande passante (généralement grâce aux technologies AJAX).
- Des fonctions d’interface (langues, émoticones…).
- De l’intégration à Drupal (au système de taxinomie, à la gestion des utilisateurs et des droits).

Projets officiels

Chatbox - Shoutbox
http://drupal.org/node/10720
http://drupal.org/node/10720
Les projets de chat les plus anciens, mais à mon avis, ils sont recommandables pour les seules personnes n’ayant aucun problème d’hébergement. Ils n’utilisent pas AJAX et consommeront plus de bande passante que les modules plus récents. Ces modules ont cependant l’avantage d’être compatibles 4.7 et d’être plus matures.

Yshout Ajax Chat
http://drupal.org/node/66026
C’est intégration d’un Chat dans un bloc. Il a le double avantage d’être compatible 4.7 et d’être peu consommateur de bande passante. Par contre l’intégration avec Drupal est limitée au minimum. Même l’apparence devra sans doute faire l’objet d’adaptation en modifiant des fichiers CSS et html. Il demeure cependant simple d’installation et n’utilise pas de base de données.

Phpfreechat
http://drupal.org/node/62389
C’est l’intégration d’un Chat autonome à Drupal (www.phpfreechat.net). Les fonctions de Chat sont vraiment complètes. Le module utilise Ajax pour économiser la bande passante et n’utilise pas de base de données. L’intégration avec Drupal est relativement complète :
- Les chats peut être attribués à du contenu ou un groupe de contenu.
- Les chats peuvent être communs ou séparés.
- Les noms d’utilisateurs sont repris automatiquement (option)
Il n’y a que deux problèmes majeurs :
- Actuellement non compatible 4,7
- Le système de droit de Drupal n’est pas encore implémenté (mais le Chat peut être lui même inclu dans un contenu dont l’accès est limité).

Projets officieux

Ajax Chat
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/chat/
Un Chat en développement qui permet de converser avec un membre ajouté à sa « buddy list ». Il nécessite donc le module buddylist pour fonctionner. Il est difficile de prévoir son évolution. Ce module est complémentaire au formulaire de contact pour les communications à deux.

Chat
Intégration d’un Chat programmé en flash (www.topcmm.com). Une démonstration est disponible à l’adresse suivante : http://webs7ven.com/
Le programme est de qualité, mais l’usage de ce type de Chat reposant sur un moteur extérieur, limite l’intégration à Drupal. Au final, ce type d’approche est relativement similaire à l’usage d’une messagerie extérieure, mais consomme la bande passante de l’hébergement.

Voir aussi :

Chatroom
http://drupal.org/project/chatroom

Tribune
http://drupal.org/project/tribune

Conclusions
Pour l’implémentation d’un Chat simple, Yshout Ajax Chat offre l’avantage de la légèreté, mais l’intégration avec Drupal se limite au minimum. Actuellement, il n’y a pas de solution totalement intégrée à Drupal pour un usage intensif du Chat. PhpFreeChat sera probablement ce futur Chat de référence pour Drupal si son développement se poursuit pour être compatible avec les versions futures de Drupal.

Module Administration Menu

Ce module n’est pas un module agissant directement sur le site web mais plus un module de confort pour l’administrateur.

Il permet à l’administrateur d’accéder en un seul clic au travers d’un menu situé en haut de la fenetre à n’importe quelle partie du menu d’administration.

Paramétrages

Son paramétrage se fait par la partie : Administrer > Configuration du site > Administration menu ( ou admin/settings/admin_menu ).

Ce module n’a pas besoin de paramétrage pour correctement fonctionner, les paramètres par défaut suffisent.

Avantages

La navigation dans le menu est énormément simplifié et le temps a passer dans les différentes pages du menu d’administration s’en trouve d’autant réduit.

Le module permet aussi de connaître le nombre d’utilisateurs utilisant la plateforme drupal, de se déconnecter, de lancer le cron, le système d’update et d’aller directement sur la page d’un module installer.

Astuce

Dans la partie de paramétrage du menu se trouve un bouton permettant de reconstruire complètement le menu extrêmement utile en cas de problème d’arborescence.

Le menu peut être utilisé par des personnes autres que l’administrateur, pour cela il suffit d’attribuer aux rôles de ces utilisateurs les droits access administration menu ( module admin menu )

En bref, une fois ce module installé on se demande comment on pouvait faire sans.

Module CCK

Ce module permet de créer, lister et modifier les types de contenu ou noeud (tel que livre, page, sondage, etc…) au travers d’une interface.

Paramétrages

Ce module n’a pas de paramétrage en lui même afin de le configurer.

L’interface de gestion du contenu se trouve dans Gestion du Contenu > Type de contenu ( admin/content/types )

Avantages

Ce module permet de creer tout type de nouveau noeud (node) avec chacun leur propre catégorie.

Astuces

Il est possible grâce à ce module d’éclater un type en créant de nombreux enfants :
par exemple, il est possible au lieu d’utiliser un type actualités de creer un type actualité drupal, un type actualité drupalfr, un type actualité drupal.org, etc…

Pour commencer

Le module "Views" peut paraître complexe quand on le découvre. La bonne nouvelle, c'est que l'interface utilisateur sépare les différentes fonctionnalités. Cela signifie que généralement, nous pouvons ignorer toutes les fonctions dont nous n'avons pas besoin. Le secret de la réussite : commencer par des exemples simples, puis compliquer petit à petit.

A cause de la quantité de paramètres proposés, l'interface de création d'une vue peut paraître déconcertante au premier abord, mais en fait, il y a peu de choses à retenir. Le meilleur conseil : Partez en exploration!

L'image ci-dessous, représente l'interface utilisateur du module Views, avec ses nombreux paramètres.

Remarques:
1) Chaque vue est composée de plusieurs "affichages", chacun indiquant l'endroit où la vue s'affichera. Avec Views 1, vous pouviez configurer une vue pour apparaître sous forme d'une 'page' avec son url (chemin), ou sous la forme d'un bloc affiché dans une région de votre thème. Avec Views 2, vous pouvez créer autant d'affichages que vous voulez. L'affichage par défaut est particulier car il contient le paramètrage de base, mais il n'apparait nulle part.

2) Lorsqu'on clique sur un élément de l'interface, un nouveau formulaire s'ouvre. Pour les plus petites résolutions d'écran, vous devrez peut-être faire défiler votre fenêtre vers le bas pour voir le formulaire. Lorsque qu'un formulaire est affiché, le paramètre édité apparait en surbrillance.

3) Dans un affichage autre que l'affichage par défaut, un changement peut intervenir de deux façons différentes: soit la modification touche tous les affichages de la vue, soit elle ne touche que l'affichage sélectionné.

Lorsque vous créez un nouvel affichage, il commence par hériter de tous les paramètres de l'affichage par défaut. "Supplanter" un paramètre indique que sa mise à jour ne concerne que l'affichage sélectionné. L'interface vous l'indique en mettant les éléments en italique et en couleur plus claire. Si vous changez ces valeurs sans supplanter l'affichage, en "Utilisant la valeur par défaut", vous modifiez cette valeur dans l'affichage sélectionné, dans l'affichage par défaut ainsi que dans tous les affichages qui lui sont liés (non surchargés).

Par exemple, si vous ajoutez un filtre "Node: publié" et que vous le régler sur "oui" dans les paramètres de l'affichage de base (pour récupérer les nodes publiés), vous pourriez dans un autre affichage choisir d'afficher aussi les noeuds non publiés. Pour cela vous sélectionnez "Filtres" dans l'affichage concerné et vous cliquez sur "Supplanter". Vous pouvez désormais ôter le filtre "publié" pour cet affichage, sans affecter les paramètres de l'affichage de base ou les autres affichages non surchargés.

4) Certains éléments ont des paramètres additionnels (particulièrement les éléments de style). Normalement, quand on modifie un style qui a des paramètres supplémentaires, un 2ème formulaire apparaît automatiquement.

5) Vous pouvez quitter l'édition d'une vue en toute sécurité pour faire autre chose. Quand vous revenez dans la vue, elle est toujours présente, sauvegardée dans le cache. Sachez cependant, que dans ce cas la vue sera bloquée, ce qui signifie qu'un autre utilisateur ne pourra pas éditer cette vue sans la déverrouiller. S'il débloque la vue, vos dernières modifications sont alors perdues.

Mieux vaut avoir un plan précis pour se former à l'utilisation du module Views. Voici quelques possibilités.

Nouveautés de Views 2

Views 2 est la plus récente version majeure de Views. Elle a été spécialement conçue pour Drupal 6. Views 2 conserve toutes les fonctionnalités cardinales de Views 1, mais avec une interface utilisateur complètement réorganisée et un grand nombre de nouveautés qui étendent largement le jeu des fonctionnalités originelles de Views 1. Ce document est une comparaison point par point de Views 1 et Views 2 du point de vue de l'utilisateur. Il présente les modifications de l'UI (interface utilisateur), les nouvelles façons d'effectuer les anciennes opérations, les nouveautés les plus attrayantes de Views 2 et comment elles corrigent certains défauts de Views 1.

Interface d'administration

Après avoir installé Views 2, vous remarquerez tout d'abord que l'interface d'administration a été complètement modifiée :

Interface d'administration de Views 2

Comparée à l'ancienne interface de Views 1 :

Interface d'administration de Views 1

La nouvelle interface d'administration effectue les mêmes tâches que l'ancienne -- cataloguer toutes les vues du système, fournir des liens pour ajouter, importer des vues et accéder aux outils (Views Tools) -- mais avec une présentation plus condensée ; ainsi chaque vue est affichée sur une ligne comme un paragraphe au lieu de l'être sous la forme d'une ligne de tableau comme dans Views 1. En haut de page, un jeu de filtres a été ajouté pour faciliter la localisation des vues lorsque leur nombre devient important.

On peut accéder à l'aide contextuelle en cliquant sur la petite icône bleue représentant un point d'interrogation. Dans Views 2, l'aide contextuelle est rendue disponible par le module Advanced Help (Aide avancée), aussi pensez à installer ce module en même temps que Views 2. La petite icone d'aide bleue est disponible à différents endroits de l'interface graphique de Views 2. En particulier, vous remarquerez sa présence à côté de la description d'un affichage (display), et dans différentes parties de l'éditeur comme les chemins, les menus et ainsi de suite.

Exemple des nouveaux attributs disponibles pour les vues sont visibles dans les filtres d'entête :

1. Etiquette - L'étiquette est juste une appellation supplémentaire destinée à organiser et ordonner les vues. Les étiquettes acceptent n'importe quel caractère. Les vues qui sont fournies avec les modules gagneront à disposer d'étiquettes identiques afin d'être retrouvées plus facilement.
2. Affichage - Dans Views 1, chaque requête de vue était liée à son affichage ; en d'autres termes, vos champs, tris, filtres, et arguments ne pouvaient être affichés que dans le seul affichage de page ou de bloc indiqué au moment de la définition de la vue. Dans Views 2, les affichages de vues ont été séparés des requêtes - il est à présent possible de définir différents affichages (pages, blocs ou fluxs) à partir d'une même vue. Vous trouverez des explications supplémentaires sur l'affichage des vues plus loin dans ce document.
3. Type - Les types de vues dans Views 2 sont complètement différents de ceux de Views 1. Les types de Views 1 désignent essentiellement la façon dont les affichages de listes de noeuds sont présentés - c'est à dire « noeuds complets » (Full Nodes), « noeuds résumés » (Teaser List), « tableau » (Table View), et ainsi de suite. Dans Views 2, la présentation des affichages a été déplacée dans un attribut Style séparé. Les types de vues se rapportent maintenant à la table principale dans laquelle l'information de la requête est retournée. Ils définissent quels arguments, quels champs, quels critères de tri et quels filtres seront disponibles. Les types de vues de Views 2 seront présentés plus loin.

Ajouter une vue

Bon, sautons le pas et ajoutons une vue. Pour cet exemple, nous avons créé une vue utilisateur destinée à afficher une liste d'utilisateurs.

Ajouter une vue

La première étape de l'ajout d'une vue consiste simplement à indiquer un nom (seulement des caractères alphanumériques, pas d'espaces), une description, une ou plusieurs étiquettes, et un type de vue.

Configuration de la nouvelle vue

La configuration de la vue est le deuxième élement dont l'interface a été complètement revue depuis Views 1. Le meilleur moyen de résumer cela est de dire que toutes les parties de l'interface de Views 1 sont toujours présentes... mais à des emplacements différents. Champs, arguments, critères de tri ou flitres, ils sont tous là, mais agrémentés d'un zeste d'Ajax.

Commençons par ajouter quelques champs :

Ajout de champs

Cliquer sur l'icone [+] située juste après le mot « Champs » fait apparaitre une section située sous les informations de la vue avec tous les champs disponibles. Ils sont groupés par Commentaire, Champ, Node, Révision, Taxonomie et Utilisateur, et probablement quelques autres. C'est un principe de fonctionnement général à l'interface de Views 2 -- cliquer sur un widget ou un lien fait apparaitre, sous les informations de la vue, une section affichant l'interface appropriée.

Lors de l'ajout d'éléments, vous pouvez utiliser le menu déroulant « Groupes » pour n'afficher que la partie des champs disponibles concernée par le goupe sélectionné. Vous pouvez aussi sélectionner « <Tout> » (<All>), qui correspond à l'affichage par défaut lorsque la section apparait. Dans notre exemple, nous sélectionnons le groupe « Utilisateur » et nous ajoutons les champs : Utilisateur : Adresse électronique, Utilisateur : Nom et Utilisateur : Portrait.

Ajout de champs

Lorsque les champs ont été ajoutés, il apparaissent dans la section « Champs » de l'interface. Chacun des champs ajoutés va être passé en revue successivement. Nous cliquons alors simplement sur Mise à jour, même si nous n'avons effectué aucune modification, et le champ suivant s'affiche à son tour.

Les champs que nous avons ajoutés peuvent être réordonnés en cliquant sur l'icone affichant deux petites flèches, l'une ascendante et l'autre descendante, située à la droite de l'icone utilisée précédemment. Nous pouvons aussi retirer un champ en utilisant la même interface.

Réordonner les champs

A partir de là, vous pouvez glisser les champs vers le haut ou vers le bas en utilisant la petite croix flèchée et en la déplacant comme bon vous semble. Effectuer une modification de n'importe quelle partie de la vue en cliquant sur « Mise à jour » provoque habituellement un rafraichissement de la prévisualisation. Celle-ci est commodément située juste en dessous de l'interface principale.

Prévisualisation de la vue

Maintenant que nous avons configuré quelques champs, nous pouvons porter notre attention aux réglages de base de la vue.

Il est important de remarquer que tous les élements de l'interface dépendent de l'affichage (display) actuellement sélectionné pour la vue. Comme indiqué plus haut, une vue peut avoir de multiples affichages. Juste après avoir créé une vue, le seul affichage disponible est l'affichage par défaut (Defaults). Vous pouvez ajouter de nouveaux affichages en utilisant le bouton « Nouvel affichage », chacun d'eux a une configuration de base complètement différente de celle des autres ; cela vous permet d'avoir autant d'affichages de la vue que vous voulez. Tous ont en commun des éléments comme Critères de tri, Filtres et Arguments mais chacun d'eux a des configurations d'affichage différentes tels que les paramètres Titre, Style, Champs, et Pagination. De plus, chaque affichage que vous ajoutez hérite automatiquement des paramètres de l'affichage par défaut ; vous pouvez donc configurer un noyau de paramètres communs dans l'affichage par défaut et ajouter les paramètres additionnels pour chacun des autres affichages.

Ajouter un affichage de Page

Restons fidèles à l'affichage par défaut et modifions quelques réglages. Nous pouvons configurer le Titre en « Vue 1 d'utilisateurs » et le Style en Tableau. Comme indiqué plus haut, les styles de vues dans Viws 2 correspondent plutôt aux types de vues de Views 1.

Sélection du type de vue dans Views 1

Dans views 2, les styles de vue définissent la façon dont un affichage de vue apparait. Ces styles sont notablement différents des types dans Views 1 ; en particulier, les types ont été « cassés » ; dorénavant,; le style tout comme le style de ligne s'occupent de parties différentes du rendu.

Schéma du rendu d'une vue

Nous modifions le style en cliquant sur le style courant situé sur la partie gauche de la zone d'information de la vue.

Sélection d'un style d'affichage dans Views 2

Les options de style disponibles sont Grille, Liste HTML, Tableau et Non mis en forme. Des styles d'affichage supplémentaires peuvent être ajoutés par des modules disposant de plugins de style pour Views. Choisir un style fait apparaitre un bouton « Paramètres » que vous pouvez cliquer pour configurer le style que vous avez choisi. Dans l'aperçu ci-dessous, nous avons sélectionné et configuré le style Table, qui est utilisé pour produire un rendu plus compact que le précédent.

Sélection et configuration du style Table

Views : Définition

Le module «Views» permet aux administrateurs et aux créateurs de sites de créer, gérer et afficher des listes de contenu. Chaque liste gérée par le module «Views» est appellée «vue» (view) et son résultat est appelé un affichage (display). Les affichages peuvent être de type bloc ou page, et chaque vue peut avoir plusieurs affichages. Des aides à la navigation, comme le chemin système et un élément de menu peuvent être définis par les affichages de type page. Par défaut, on peut créer des vues pour lister des noeuds (vue de type Node), des révisions de contenu (vue de type Révision du nœud) ou des utilisateurs (vue de type Utilisateur). On peut restreindre l’accès à une vue à des rôles spécifiques.

On ajoute, supprime ou modifie une vue via la page d’administration de Views

Le design du système de Views est puissant et flexible, permettant de spécifier des paramêtres seulement si on en a besoin. Alors qu’une vue avancée peut nécessiter d’utiliser tous les paramêtres pour créer des applications complexes ayant un taux d’interactivité élevé, une simple liste peut être créée avec très peu d’options.

Toutes les vues se basent sur un cadre conceptuel (conceptual framework) qui inclus :

• Les Champs sont les plus petits morceaux de contenu qui puissent être affichés. En ajoutant par exemple les champs Node : Titre, Node : Type et Node : Date de publication à une vue de type node, on obtiendra une liste incluant, pour chaque noeud, son titre, son contenu et sa date de publication.
• Les Relations, indiquent comment les données sont liées les unes aux autres. Si une «relation» existe telle que les informations fournies par un champ CCK node référence, le contenu d’un noeud lié peut être inclus dans la vue.
• Les Arguments sont des paramètres additionnels qui permettent de restreindre les résultats dynamiquement, via l’url. Par exemple en ajoutant un argument de type Node : Type à une vue de type node et en définissant son chemin comme «contenu», on filtre dynamiquement le contenu par type de contenu. Par exemple en accédant à la vue à l’adresse «http://www.example.com/contenu/story» on liste tous les contenu de type article alors que «http://www.example.com/contenu» liste tous les contenus, quels que soient leur type.
• Les critères de tri, qui déterminent l’ordre dans lequel les données seront affichées. Par exemple, en ajoutant le critère de tri Node : date de publication (en ordre descendant), on trie la liste par date de publication, du plus récent au plus ancien.
• Les Filtres, qui permettent de limiter les résultats affichés. Par exemple en ajoutant le filtre Node : Publié = oui empêche les éléments non publiés d’apparaître dans les résultats.
• Les Affichages, qui contrôlent comment le résultat sera affiché. Chaque vue a un affichage par défaut qui, dans l’absolu ne génère aucun affichage mais qui est utilisé pour stocker les paramètres par défaut et pour afficher des vues par la programmation lorsqu’aucun autre affichage n’est défini. Les affichages de type page qui donnent à la vue une url qui permette à la vue d’être le contenu principal d’une page, et ceux de type bloc qui permettent d’afficher le résultat dans un bloc de contenu secondaire sont beaucoup plus utiles pour l’utilisateur.

Intégration de view via php

Lorsque l’on crée une vue il est possible de créer différents affichages (défaut, page ou encore bloc) mais il n’est pas possible d’intégrer votre vue dans une page à un endroit spécifique. Pour cela il existe des modules comme insert_views qui permettent d’insérer une vue dans une page en ajoutant une simple ligne de code. Le problème est qu’il faut faire attention à chaque fois que vous éditez votre page que votre vue fonctionne toujours surtout si vous utilisez un éditeur Wisywig. Il existe sinon une autre solution, qui consiste à intégrer votre vue en Php.

Je passe la partie création du module, mais pour réaliser ce qui suit il vous faut l’avoir crée.

Nous allons utiliser la fonction views_embed_views($name, $display_id = ‘default’) qui n’a besoin que d’un seul paramètre (nom de la vue) pour fonctionner.

Le code ci-dessus nous permet d’afficher la vue portant le nom MY_VIEW_NAME

En lisant la fonction views_embed_views on s’apercoit que celle-ci autorise un deuxième paramètre ($display_id) qui gère l’affichage (exemple : default, page, block, etc) et va nous permettre de choisir le format de sortie. Bien souvent, lorsque l’on crée une vue c’est pour afficher des résultats variables selon un paramètre comme une liste en fonction d’un terme de taxonomie. Ainsi pour passer un argument à notre vue nous allons ajouter un troisième paramètre à notre fonction.

Il ne vous reste plus qu’à choisir ou intégrer cette vue.

Ce que nous venons de voir est facile à mettre en place pour afficher le contenu d’une vue, mais cela ne nous laisse que très peu de contrôle sur notre vue. Par exemple views_embed_views n’affichera pas le titre que vous aurez saisi dans votre vue.

Pour aller plus loin nous allons utiliser la fonction views_get_views($name, $reset = FALSE) qui va nous permettre d’accéder à plus d’information.

Comme toujours il existe pas mal de fonctions et de possibilités pour générer une vue, dans la majorité des cas la première solution est la plus utilisée.

Comparaison du module patterns et du module features

N’hésitez pas à corriger les informations données ici , je n’ai pas la prétention de faire une véritable comparaison définitive, je donne simplement des pistes de réflexions pour ceux qui hésitent entre les deux.
Cet article ne demande qu’à être amélioré et ajusté par ceux qui connaissent bien le module patterns.

Vous trouvez en fichier attaché au bas de l’article un petit tableau comparatif, surement incomplet pour l’heure

http://drupalfr.org/sites/default/files/comparatif.png

Vous pouvez téléchargez le module patterns ici.
http://drupal.org/project/patterns

Notez enfin qu’il est tout à fait envisageable d’utiliser à la fois patterns et features en même temps sur un site selon le type de routine à automatiser.

Introduction

Patterns est un module très intéressant et ingénieux permettant d’écrire un fichier xml qui permettra, à son import, de configurer automatiquement des pans de votre site avec des informations de configurations très poussées. En rédigeant votre code xml (ou yaml ou php), vous pouvez créer des types de contenus, des champs CCK, des presets image cache, des nodes, des blocks, de la taxonomie, des utilisateurs. Son champ d’action est très large et le degré de précision impressionant. Je vous conseille vivement de lire l’article suivant sur drupalistic pour d’autres renseignements et un exemple sympa de pattern :
http://www.drupalistic.net/module/patterns

Comment fonctionne pattern ? exemple

Pour faire fonctionner pattern, nous devons rédiger un document xml que nous importerons ensuite dans l’administration du module patterns. Un pattern (et le fichier xml) est divisé en trois gande parti : description du pattern, modules requis, actions à effectuer lors qu’on lance le pattern.

cas utilisateur : nous voulons créer automatiquement un type de contenu news, en y ajoutant un champ image field.

La description de notre pattern

Ces quelques lignes permettent de décrire notre pattern. Ils sont indispensables.

Les modules requis pour le fonctionnement de notre pattern

Maintenant on doit réfléchir aux module dont nous avons besoin  : dans mon cas utilisateur je veux utiliser une champ image avec image field et controler la retaille d’image avec image cache. Image cache dépend de image api, image field dépend de file field et de content. On va aussi inclure le module Image cache UI pour pouvoir retoucher dans une interface utilisateur nos presets au besoins.
J’insére ceci juste après la balise de fermeture , pour déclarer les dépendances à activer :

Les actions de notre patterns

On entre dans le vif du sujet. Créeons notre type de contenu « news ». Toutes nos actions devront être placés entre les balises actions. Je donne le nom machine et humain du type de conteu, je précise que je veux activer les commentaires, ne pas activer l’upload, que les news soient publiées par défaut, et que ce type de contenu ne soit pas promu sur la page d’accueil.

Si on lance notre pattern, tout fonctionne à merveille et le type de contenu se crée à la perfection. Rédiger un type de contenu s’avère donc un jeu d’enfant. Comme patterns utilise l’API des formulaires de Drupal, on peut controler absolument n’importe quel paramètre du type de contenu : nombre de commentaires par page, type de commentaire,etc, etc…. Avec le module features, nous aurions eu besoin d’implémenter un hook dans le fichier .module pour pouvoir affiner les réglages des commentaires, de l’upload et du status de publication.

Rajouter un champ CCK

Nous sommes toujours au seins des balises actions . J’ajoute un champ filefield avec l’option « image » que me confère le module image_field, je décide que 5 images sont autorisées par article

Si on veut rajouter de la taxonomie, des presets d’image cache , des nodes, des blocks ?

La syntaxe pour tous ces objets sera tout aussi facile à rédiger, et la finesse de configuration toujours aussi pointue. Même si les premières fois il va falloir réfléchir et tatonner pour trouver les bon noms de paramètres pour le xml.

Comment créer une vue avec pattern ?

A compléter : je n’ai pas eu le temps de comprendre comment créer une vue avec patterns. Une chose est sure, sur ce point, le module features a un énorme avantage car il permet d’exporter des vues et de les incorporer à notre feature en un seul clic : tandis que patterns, de par le fonctionnement du module, va vous demander de remplir de nombreuses informations pour reproduire une vue. Features à un très sérieux avantage pour l’instant de ce côté puisqu’il permet en un clic d’exporter une vue en profitant de l’API d’export de views.

Quelle sont les différences entre features et patterns ?

Ils ont un objectif commun : pouvoir réutiliser sur un nouveau site les configuration de modules patiemment créer sur un autre site. Mais pour cela ils utilisent une méthode très différente :
- Patterns s’appuie sur l’API des formulaire de Drupal. C’est à dire qu’à partir du xml que vous lui fournissez, il va soumettre programmatiquement les formulaires de configuration tout comme si vous le faisiez vous même. A part qu’il va beaucoup plus vite que vous :-). Vous obtenez donc le même résultat que si vous aviez fait tout ce travail à la main.

• Features agit d’une manière différente : il s’appuie sur l’API d’exportation des modules pour exporter leur configuration puis stocker cette configuration dans un fichier. Il extrait finalement les données présentes dans la base de données pour les mettre dans un module. Ce module devient ensuite un «donneur d’ordre» : il dit à image cache ou à CCK de créer telle ou telle chose, mais si on désactive la feature, tout disparait.

Exemple concret de cette différence : un type de contenu importé par patterns sera enregistré dans la base de données tout comme si vous l’aviez créer vous même à la main. Vous aurez un bouton delete vous permettant de l’effacer. Tandis que le type de contenu sauvegardée par feature sera contenu dans le fichier du module. Le type de contenu n’apparait que si vous activez la feature, vous n’aurez pas de bouton «delete» car ce type de contenu ne sera pas stocké dans la base de données. En revanche tous les élements créer par feature disposerons d’un bouton «revert» permettant de retourner à la configuration originelle donnée par votre feature.

Les avantages de patterns

• un large champ d’action et de possibilité. Un haut degré de précision. Pour en faire autant avec features, vous devrez installé le module strongarm et implémenté un hook_strongarm dans le fichier .module de la feature.

• possibilité de créer des vocabulaires, des termes, des nodes, des utilisateurs, des roles. Feature ne le fait pas de base. Patterns semble également très souple sur la gestion des blocs.

• L’idée de s’appuyer sur l’API des formualaire est ingénieuse : cela permet virtuellement de pouvoir s’adapter à n’importe quel module.

• La possibilité d’imbriquer des patterns dans des patterns. Cela permet sans doute de faire des features plus « configurable ». on peut imaginer un pattern qui créer le type de contenu news, le bloc, les tags, sans créer les images avec leurs presets. Ces images pourraient être un autre pattern que l’on peut selon nos besoin inclure ou pas dans notre pattern. On peut donc faire des patterns de patterns. :-)

• intégration avec pathauto

• Tout au même endroit :-) Tout se trouve exclusivement dans le fichier xml (ou autre format) sans une goutte de code php. Cette homogénéité est plaisante.

• j’en oublie surement, libre à vous d’éditer cette liste.

Les inconvénients de patterns

• Aucune interface utilisateur pour générer automatiquement votre xml. La page d’administration du module est actuellement incomplète, ne permettant pas de supprimer ( ou de désactiver un pattern ). (en tous je n’y suis pas arrivé)

  il est donc beaucoup plus long d’écrire un pattern en xml, et cela demande beaucoup plus de rigueur, que d’utiliser features qui permet parfois en quelques clics de faire quelque chose d’équivalent.

• Exporter une vue et ses blocs semble laborieux alors que features peut réaliser cela en un clic.

• Pas de bouton « revert » pour l’instant comme sur features, permettant de revenir à l’état antérieur du pattern

• Pas de possibilité de désactiver un pattern comme on désactive une feature.

Avis subjectif : Pourquoi je préfère features malgré sans champ d’action apparemment plus réduit

• Grande facilité pour importer des vues et leurs blocks

• Contrairement à patterns ou on doit rédiger de zero, features requiert simplement que vous créeiez comme à votre habitude vos types de contenus etc… puis vous n’avez qu’à exporter pour obtenir votre feature.

• Pouvoir utiliser le module context.

• Utilisation possible de features avec le module spaces, même si je n’ai pas encore exploré cette partie. Mais bon, cela donne open atrium :-)

• Chaque élément fourni par une features (views, preset d’image cache, champ CCK) dispose d’un bouton « revert ». Si vous n’etes pas satisfait des nouvelles évolutions apportées à votre features, le bouton revert permet en un clic de retrouver l’état orignel de votre vue, de votre champ CCK ou même de toute votre feature.

• facilité de mise à jour : il suffit d’uploader un fichier, et en cas de pépin il suffit de réuploader une version précédente du fichier, nous n’avons pas à nous préoccuper de la base de données. Patterns est plus « barbare » : il éxécute des requetes sql et il me paraît donc IMPERATIF de faire un back up and migrate avant tout import d’un nouveau pattern. Or, c’est justement pour éviter de devoir faire des backups constant au moindre changement de la base de données que je suis intéressé par features.

• En tant que développeur PHP, features me permet d’implémenter mes propres hooks en additions de la features, cela me donne donc une liberté totale, je ne suis dons pas frustré de certaines limites de features par rapport à patterns.

• une certaine confiance en Development Seed : j’aime leur travail de réflexion sur Drupal et les solutions qu’ils apportent. A priori features me parait promis à un plus bel avenir que patterns, mais je peux être dans l’erreur.

Prise en main détaillée des modules context et features

Introduction à Features and Context

Avertissement : cet article s'adresse plus particulièrement à des utilisateurs avertis ou des professionnels de Drupal. Il se veut une aide pour prendre en main le trio de modules spaces/context/features dont la documentation reste laconique pour le moment. Module requis pour suivre l'exemple donné dans cet article

• Context http://drupal.org/project/context

• Feature http://drupal.org/project/features

• CCK http://drupal.org/project/CCK

• Views http://drupal.org/project/views

• Image field http://drupal.org/project/imagefield

Il est fortement conseillé d'utiliser le theme Garland pour suivre cet article; tous les thèmes n'étant pas forcément compatible avec le module context. Je reviens sur ce point en fin d'article.

Théorie : Pourquoi utiliser context et features

Il y a peu de temps, la société Development Seed annonçait la sortie d'Open atrium, un intranet bâti sur Drupal et donc la structure repose en grande partie sur trois modules : spaces, context and features. Plus que de simples modules développés uniquement pour l'occasion, spaces context et features se veulent une véritable redéfinition de la manière de développer Drupal. Ces modules apportent en partie une solution aux problématique suivantes que rencontrent ceux qui font de nombreux sites avec Drupal :

1 - On refait souvent sur un site ce qu'on avait fait à l'identique sur un précédent site

On se retrouvent souvent à combiner puis configurer les même modules pour répondre au même besoin. Par exemple peut être que pour chaque nouveau site, vous créez un type de contenu « news », avec un champ CCK « image field », lui même utilisant un preset du module « image cache » afin que votre client puisse poster régulièrement des actualités sur son site, assortie d'une image retaillée à la volée par image cache. Ne serait-il pas pratique de pouvoir « sauvegarder » tout ce travail de configuration pour pouvoir ensuite l'importer sur un autre site sans avoir à tout refaire ? C'est ce que permet features.

2 - Probleme de mise à jour d'un site en ligne et de workflow de production :

Si vous diposez d'un site en ligne, et que vous souhaitiez importer sur celui-ci les dernières fonctionnalités développées dans un environnemt local, vous devrez faire deux choses :

importer en ligne les fichiers qui ont changés écraser la base de données du site en ligne pour la remplacer par celle du site en local

En effet votre base de données locale contient toute la configuration des modules que vous venez de savamment ajuster. Problème : écraser la base de données du site en ligne signifie aussi écraser le contenu (les articles) du site en ligne ! Features propose une alternative à cette manière de procéder en exportant la configuration de vos modules dans un fichier PHP (sous forme de module Drupal que l'on peut activer/désactiver). En uploadant ce fichier sur le serveur, vous pouvez mettre à jour la configuration de vos module sans être contraint d'écraser votre base de données de destination.

3 - Manque de lisibilité de l'administration d'un site Drupal :

Pour créer une fonctionnalité poussée sur un site Drupal, vous allez utiliser (par exemple) une combinaison plus ou moins complexe de champs CCK, de différentes vues, de placement de blocs avec leurs paramètres de visibilité; cela dans le but de répondre à un besoin utilisateur bien défini et facilement formulable tel que « créer une galerie d'images » ou « pouvoir poster une news sur le site ». Pourtant en ouvrant ensuite votre administration de Drupal; rien ne montre clairement que tels champs CCK + tel type de contenu + telles vues + tels blocs + tels modules travaillent ensemble pour permettre la création d'une galerie d'images. Vous êtes le seul à le savoir. Au fur et à mesure que votre site grossit, il devient de plus en plus difficile de s'y retrouver dans une administration devenue un véritable jungle de formulaires de configuration. Tous vos réglages sont physiquement éparpillées aux 4 coins de la base de données sans vous donnez aucune possibilité de vue d'ensemble de votre travail de configuration.

Context et features permettent en partie de retrouver une solution à ce souci de lisibilité. Si vous construisiez votre site en vous basant autant que possible sur ces modules, vous pourrez alors voir dans la page d'administration de features en un coup d'oeil toutes les features que vous avez développé pour le site; et en cliquant sur une feature en particulier vous pouvez observer la composition d'une features qui vous indique avec quels modules elle fonctionne, de quel module elle dépend etc.... De même, la page context permet également facilement de voir quels sont les blocs et type de contenus associés sur une section particulière du site.

En pratique : Comment utiliser context ?

Créer les éléments pour construire un blog simple

Prenons un exemple concret: Imaginons qu'un client, qui utilise Drupal pour son site vitrine, souhaite ajouter sur son site un espace réservé à un petit blog qui décrira au jour le jour l'activité de son entreprise. Pour ce faire, nous allons créer un type de contenu « billet_de_blog », et nous allons créer une vue « blog » avec pour chemin « blog », qui sera chargé de lister les teasers avec pagination de tous nos types de contenus « billet_de_blog ». Pour rendre le tout un peu plus sexy nous allons aussi ajouter :

un bloc avec les dernières commentaires postés sur le blog, en utilisant une vue de type bloc. un bloc « archive » qui va permettre au visiteur de voir tous les articles d'un mois particulier en cliquant sur le nom d'un mois. Une page « archive » fournie par une vue, qui permet de naviguer dans les articles d'un mois donné. (par exemple : voir tous les articles du mois de novembre)

Nous allons aussi utiliser le module image field afin d'ajouter à notre type de contenu un champ CCK qui permettra à notre client d'uploader une image pour chaque article. Pour la vue en archive, utilisez tout simplement celle (désactivée par défaut) que propose le module views, il vous suffit de l'activer pour qu'elle soit opérationnelle ainsi que son bloc avec la liste des mois cliquables. Il vous faudra simplement ajuster le filtre de la vue pour qu'elle ne liste que le type de contenu « billet_de_blog ».

Utiliser context pour mettre nos blocs en place

Une fois tout cela crée, nous allons entrer dans le vif du sujet et commencer par placer nos blocs « derniers commentaires » et « archive list » dans la colonne de droite de notre blog. Pour donner l'impression d'un espace homogène sur tout le blog, nous voulons logiquement que ces blocs s'affichent en réalité à trois endroits différents :

• sur notre vue listant nos articles

• sur nos articles proprement dit lorqu'il sont vus en « full node »

• sur notre vue archive

C'est l'assemblage de ces trois entités distinctes qui va définir l'espace de notre blog. Context va justement nous servir à créer une définition de cet espace, et à ensuite placer des blocs dans des régions lorsqu'on se trouve dans cet espace.

Surtout, c'est très important, ne vous rendez PAS dans la page des blocs classique de Drupal pour placer vos blocs car c'est avec le module context qui nous allons gérer désormais leur positionnement : or context ne peut gérer le positionnement d'un bloc que si celui-ci n'est PAS positionné au prélable par la page de gestion classique des blocs.

Installez donc le module context si ce n'est pas déjà fait puis rendez vous dans l'onglet construction du site où frétille maintenant d'impatience un nouveau lien « context ». Ajoutez un nouveau context qui va nous servir à définir notre contexte « blog ». Alors là normalement si c'est la première fois que vous utilisez context vous devriez lever votre sourcil gauche en marmonnant un grognement circonspect à la vue des trois premiers champs qu'on vous demande de remplir pour la création d'un context : « namespace », « attribute» « value ». On boit une gorgée de café et on garde son sang-froid.

En gros imaginez d'abord cela comme un systeme pratique de classement : tous les contextes qui auront un « namespace » et « attribute » identiques seront classés ensemble. Si vous avez une quinzaines de contextes sur un site, ils seront regroupés par espace (namespaces) / attributes identiques. A cela s'ajoute le fait que features pouvant fonctionner de paire avec le module spaces, il semblerait que la convention de nommage « spaces » pour le namespace et « feature » pour attribute permettent au delà du simple classement de tirer parti du module « space », mais je n'en suis pas sûr ...

Le module space mériterait en lui même un article et n'a pas de rapport direct avec notre problématique pour le moment. Toufefois, pour satisfaire les plus curieux, vous pouvez concevoir les « spaces » comme des sections de votre site pour lesquelles vous pourrez activer ou désactiver des features. Chaque espace pouvant activer une feature sans que la même feature sur un autre espace soit activée. C'est ce qui vous permet dans Open Atrium d'activer ou de désactiver de grosses fonctionnalités (blog, casetracker, shoutbox) en fonction d'un organic group; car le module spaces dispose d'une extension spécifique pour organic groups. Donc les espaces sont à imaginer comme des « prises » pour brancher les features, une section du site où elles deviennent valides. Physiquement, les espaces peuvent être visibles grâce à un préfixe d'url ajouté par le module « purl » (requis pour faire tourner spaces).

Mais revenons à notre contexte :

Pour l'instant, un remplissage possible de 3 propriétés de votre contexte serait par exemple :

• namespace : « communication » (Le blog est un outil dont le client se servira pour communiquer en temps réel sur la vie interne de sa société.)

• attribute : « blog » (peut être mettrez vous plus tard à disposition de votre client d'autres outils de communication, comme une galerie photo ou des podcasts etc...)

• value : « partie_publique » (on peut imaginer que vous créiez un autre contexte ensuite qui auront le même namespace et attribute mais avec pour value « partie_admin »; contexte que vous utiliseriez pour offrir au client une page d'admin lui permettant de gérer son blog comme sur un vrai blog de type wordpress).

Vous avez aussi un petit champ description pour exprimer avec une prose condensé l'essence intime de ce contexte à vos yeux. Si vous avez un seul contexte sur votre site, vous auriez tout aussi bien pu marqué dans chacun des champs « blog » et cela aurait tout aussi bien fonctionné. Mais sur un site plus important, il sera bon de rationnaliser comme je viens de le faire vos contextes pour gagner en clarté. De plus, ce travail de formulaire oblige à une certaine clarification / classification des besoins utilisateurs à développer, ce qui ne peut pas faire de mal.

Maintenant on s'attaque au plus fun : configurer votre contexte. Vous allez notamment vous apercevoir à l'usage que context permet de placer/déplacer des blocs beaucoup plus vite que par l'interface classique des blocs, (qui en plus rame particulièrement et s'avère peu ergonomique quand un site dispose de nombreux blocs).

L'interface de configuration de context se divise en trois grandes parties :

• les conditions : qu'est ce qui va déclencher l'activation de votre contexte « communication > blog > partie publique «  ?

• les réactions : qu'est ce qu'il se passe quand ce contexte est actif ? Elles sont assez limitées pour l'instant; on peut désactiver une région entière du template, envoyer 3 nouvelles variables à notre page.tpl.php , rendre un item de menu actif. Les variables sont intéressantes puisqu'elle permettent d'afficher dans votre theme le titre de la section à travers tout le contexte. Dans notre cas, on pourrait afficher « le blog de la société ».

• Le placement / la visibilité des blocs dans ce context. Quels blocs va afficher notre contexte et dans quelle région ? Choisissez un bloc dans la partie droite plus cliquez sur « add » dans la partie gauche de la région visée.

Concernant les conditions et les réactions, les développeurs seront ravis d'apprendre que le module context vous proposent une séries de hooks permettant de créer très rapidement et très facilement de nouvelles conditions / réactions pour enrichir context sans hacker le module.

Nous voulons que notre contexte soit actif dans les conditions suivantes :

• quand on se trouve sur un type de contenu « billet_de_blog ». cliquez simplement sur « node pages » puis cochez le type de contenu pré-cité.

• Quand on se trouve sur la vue « archive » et la vue « blog ». Cliquez sur « views » et sélectionnez les vues. (déjà à ce stade vous devriez déjà vous rendre compte qu'en 4 clics vous faites la même chose, et bien plus rapidement, qu'avec un paté de 10 lignes de php pas lisible dans la configuration de visibilité d'un bloc).

Maintenant choissiez dans les blocs votre bloc « derniers commentaires » ainsi que le bloc « archive list » généré par la vue archives. Et voilà ! En vous rendant sur les types de contenu blog et sur vos vues, vous constaterez la présence studieuse de vos blocs.

Au passage on peut signaler un autre avantage de context qui n'est pas des moindres : si pour une raison X ou Y vous devez afficher ces mêmes blocs sur un autre type de contenu, l'affaire sera réglée en quelques secondes. En passant par l'interface classique des blocs, il vous faudra ouvrir chaque bloc, modifier votre code php dans la visibilité des blocs, ce qui conduit assez vite à la déprime si cela concerne dix blocs.

note importante : pour placer les blocs, il est impératif que votre theme n'utilise pas un override de la fonction « theme_blocks » (dans template.php). Si c'est le cas, le placement des blocks de context ne fonctionnera pas. A noter aussi un conflit avec le module i18n, car il n'est pas possible d'afficher un bloc avec context en fonction de la langue. Toutefois il reste possible de placer des blocs dont l'affichage est indépendant de la langue, à condition toutefois d'allouer un poids supérieur au module context dans la table system.

Pensez aussi maintenant à ajouter votre champ CCK sur le type de contenu « billet_de_blog » afin que l'utilisateur puisse uploader une photo sur son blog.

premières conclusions :

L'utilisation de context nous a permis en seulement quelques clics de définir des conditions complexes de visibilité pour nos blocs qui demanderait en temps normal un peu de php; tout en offrant en plus une interface (la page d'administration de notre contexte) permettant de voir en un coup d'oeil quels sont les blocs et vues qui travaillent ensemble pour définir notre espace de blog. Mais le plus grand intérêt de toute ceci n'est pas là : en utilisant context nous trouvons surtout le plus fidèle allié du module features, c'est à dire que tous ces réglages vont pouvoir désormais être exportés, et c'est là tout l'intérêt de notre démarche, qui permet de résoudre en partie le probleme de la mise à jour d'un site en ligne Drupal. Bref, tout ceci n'était que la première étape de notre plan machiavélique.

Exporter votre fonctionnalité blog avec le module features

C'est maintenant l'heure de vérité : installez le module features, puis rendez vous dans le menu « construction du site » et cliquez sur le nouveau lien « features ». Comme vous n'avez pour l'instant créer aucune feature, cette page doit être vide, nous allons donc nous empressez d'ajouter une feature pour y remédier. Choisissez le nom de votre feature : ce sera le nom du module que vous obtiendrez ensuite. Indiquez également la version, car vous exporterez sans doute votre feature plusieurs fois au cours de votre développement. Ignorez pour le moment le champ « update feed » : il vous servira quand vous travaillez avec un serveur de features qui s'avera un outil extrement pratique pour stocker de façon ordonnée et sûre vos créations (et qui, si il est en ligne, vous permettra de partages vos features avec les autres utilisateur de Drupal ).

Nous allons définir notre feature; c'est à dire que nous allons expliquer à feature quels sont les éléments composant notre fonctionnalité blog afin qu'il puisse exporter tout ça dans un fichier php (un module); ce qui nous permettra de l'installer ensuite en un seul clic sur n'importe quel installation Drupal sans avoir à recréer manuellement tout ce que nous venons de faire.

Vous devez disposez dans le formulaire de création de feature d'une liste déroulante pour choisir les « objets » faisant partie de votre feature : node, context, views, users etc... Sélectionnez en premier votre context, qui permettra de récupérer automatiquement un grand nombre d'informations concernant notre fonctionnalité blog. Ajoutez-y le type de contenu « blog » afin de récupérer les informations concernant le champ CCK que vous avez ajouté. Vérifiez que tous les éléments liés à votre blog aient bien été détectés et ajoutez ce qu'il manque au besoin. Vous remarquez que l'objet « user » de la liste déroulante vous permet d'exporter la configuration de certaines permissions Drupal ! Cela vous évitera d'avoir à passer par la page permission pour reconfigurer les droits lors de l'installation de votre feature sur un nouveau site ou lors d'une mise à jour.

Enfin, c'est une partie à laquelle il faut être très attentif, vérifiez que toutes les dépendances de votre features ont bien été détectées (c'est à dire les modules dont votre fonctionnalité blog à OBLIGATOIREMENT besoin pour fonctionner), et ajoutez en si vous pensez qu'il en manque une. Sinon, lorsque vous installerez une feature plus complexe, rien ne marchera comme vous l'espérez et rien ne vous indiquera que vous avez tout simplement oublier d'installer puis d'activer un module indispensable à son bon fonctionnement.

Une fois tout cela fait : cliquez sur le bouton « download » et, magie ! Vous pouvez télécharger votre features en tant que module !

Une fois cela fait, décompressez le fichier obtenu (une erreur se produit à la décompression mais pour ma part avec winrar cela n'affecte pas le fonctionnement de la feature, c'est un bug connu actuel qui devrait être résolu à la prochaine release), puis installez le, comme tout module qui se respecte dans votre répertoire modules. Ll'idéal est de créer un sous-dossier dans « sites/modules » permettant de rassembler toutes vos features, histoire de ne pas les confondre avec les modules classiques. Ensuite, il vous reste à activer cette feature; pour cela vous devez vous rendre à nouveau dans construction du site > features; ou vous devez voir maintenant apparaître votre nouvelle feature.

En réalité, ce que vous venez de faire ne change strictement rien au fonctionnement actuel de votre site; si ce n'est que désormais vos vues et contextes dispose de boutons « revert » fort pratiques vous permettant désormais de revenir à tout moment à la configuration contenue dans votre module. A partir de maintenant, si vous commencez à modifier une vue ou un contexte; en vous rendant sur la page feature vous verrez le statut de la feature passer de « defaut » à « overriden »; ce qui indique que vous avez apporté des modifications à votre fonctionnalité entre temps. En installant le module « diff » vous serez même en mesure de visuellement les changements que vous avez apportés par rapport à la feature originelle. Il vous est possible de revenir à l'état de la feature lors de son export en cliquant sur Revert. Si en revanche vous êtes satisfait des améliorations apportées entre temps à votre feature, il ne vous reste à l'exporter à nouveau puis à écraser l'ancien fichier avec le nouveau (en passant par l'onglet update dans la configuration de feature).

Voilà, vous disposez désormais d'une feature « blog » que vous pouvez installer à présent sur une nouvelle installation de Drupal. Celle-ci se chargera de replacer automatiquement vos blocs et de recréer vos vues. Ce petit exemple devrait vous permettre d'imaginer facilement comment tirer parti des modules context et features pour vos sites.

Conclusion

Il est temps maintenant de mesure les implications concrètes de ce que nous venons de faire :

• il vous suffit d'installer votre feature sur une nouvelle installation de Drupal pour pouvoir réactiver votre blog tel que vous venez de le configurer, en un seul clic. C'est un temps énorme économisé pour vos prochains sites qui rencontreront un besoin similaire.

• vous pouvez désormais mettre à jour le placement des blocs, des champs CCK, views etc.. uniquement en écrasant le fichier de votre module. Il n'est donc plus nécessaire d'exporter votre base de données pour communiquer des changements de configuration de modules.

• Vous disposez de la possibilité de revenir à la configuration par défaut de la feature en cas de gros pépins. Donc si vous sabotez involontaire votre super code php qui tue dans l'argument d'une vue, plus besoin de vous défenestrez parce que vous aviez oublié de sauvergarder la base de données ou d'exporter votre vue : cliquez sur « revert ». Il en va de même pour vos contextes.

• Vous pouvez partager votre feature avec les autres; donc vous pouvez aussi télécharger les features des autres. On conçoit les avantages qu'un tel module de normalisation des exportations de configuration de modules Drupal se mette en place. Tout le monde y gagnerait.

• Vous pouvez facilement faire un versionning dans vos features importantes : En installant un serveur de features (un profil drupal existe permettant de faire cela en 5 minutes), vous pourrez aisément centraliser les différents releases de vos features et entrez des notes primordiales quand à certaines choses importante à notifier pour le bon fonctionnement de la feature. Comme par exemple le theme dont elle dépend. Et puis comme le monde n'est pas parfait, il vous faudra aussi parfois tout de même retoucher deux ou trois paramètres de configuration à la main, features n'étant malheureusement pas compatible avec tous les modules; mais seulement actuellement avec quelques modules clefs pour le développement de site avec Drupal. Il est donc bon de noter sur votre serveur de feature, dans la description, les petits changements qu'il sera peut être nécessaire d'apporter une fois la feature activée pour que celle-ci fonctionne pleinement.

Limitations connues actuelles

• Le module features n'est pas magique et ne peux pas exporter la configuration de n'importe quel module. Actuellement vous ne pouvez vous en servir que pour exporter la configuration de views, les champs CCK, image cache, context (ainsi vous pouvez exporter le positionnement de blocs et leur visibilité). Concrètement, imaginons que vous exportiez votre feature en indiquant une dépendance au module « blog theme ». Blog theme permet à l'utilisateur de votre site de choisir son propre theme pour un blog. Peut être avez vous touché la configuration de blog theme pour indiquez à quel type de contenu s'adaptera le theme du blog. Ce paramètre ne sera pas exporté par features car blog theme n'est pas supporté par feature. Il vous faudra donc retoucher ce paramètre à la main ou, ou bien ajouter dans votre feature un petit module qui sera chargé lors de son activation d'automatisé ces réglages avec quelques hooks et requêtes sql.

• Le module context peut facilement être overridé par le theme au niveau du theme_blocks. Or le module context se sert justement de la fonction theme_blocks pour pouvoir placer les blocs dans votre theme. Si context s'aperçoit que le theme utilise déjà un override de la fonction theme_blocks (dans son fichier template.php), alors il laissera la priorité au theme et ne placera plus simplement aucun bloc. Sans vous le dire, ce qui peut surprendre.

• J'ai eu à faire à un cas ou la condition « path » refusait de marcher, sans doute un conflit avec un autre module mais je n'ai pas pu trouver lequel ni la raison de ce bug.

• Le module context est en conflit avec i18n : de plus, un bloc placé avec context s'affichera à la fois en anglais et en français si ce sont les deux langues utilisées sur votre site.

Ayez aussi bien à l'esprit la chose suivante : un contexte est lié à son theme. C' est un pacte signé par le sang; car context doit connaître les régions d'un theme pour pouvoir placer ses blocs. C'est tout à fait logique mais cela implique que pour vous servir de votre context; vous devez utilisez le thème pour lequel il a été crée; et donc qu'il est dépendant d'un theme en particulier. A noter tout de même également que beaucoup de themes ont en commun les région $left et $right; donc vous avez un une probabilité assez élevé que les blocs que vous avez placé dans la barre de droite se retrouve au bon endroit en utilisant un autre theme.

Autre point : Il n'est actuellement pas possible de choisir pour quel theme activé de Drupal votre contexte s'applique : il s'applique forcément sur votre theme par défaut. C'est très dommage car cela limite la puissance potentielle de ce module, mais cela sera très certainement corrigé dans la prochaine version du module car intrinsèquement il est tout à fait capable de gérer ce point sans problemes. Sur le dernier projet sur lequel j'ai travaillé, j'ai contourné cette limitation en renommant les régions de mon deuxieme theme avec les mêmes noms de régions que celle de mon premier thème. C'est parce que context a besoin de connaître votre theme pour afficher les régions disponibles qu'il n'est pas possible d'afficher actuellement un theme particulier en fonction du context. C'est une demande fréquente mais c'est en fait quasiment un contre-sens pour l'instant étant donné la manière dont le module fonctionne.

Malgré les mises en gardes que je vous adresse, qui sont parfois handicapantes, ne jetez pas trop vite le bébé avec l'eau du bain : ces limitations peuvent ne pas peser très lourd en comparaison des bénéfices apportés par le module: à vous de voir selon les situations. Context est un module encore jeune destiné à évoluer. Mais ça peut valoir le coup, quand vous avez plusieurs manières de procéder pour developper une fonctionnalité; de privilégier les modules exportables par context.

Autres modules existants pour exporter votre configuration

Les moyens suivants permettent comme features d'exporter vos paramètres puis de les importer. Ils ne sont pas forcément antagonistes avec features et peuvent sans doute être complémentaires. Je n'ai pas testé toutes ces possibilités je ne peux donc pas faire une comparaison.

• Le profil d'installation drupal. Très puissant mais un peu difficile à appréhender : il est l'outil idéal pour packager votre installation Drupal d'une manière ou d'une autre. Par exemple vous pourriez vous faire un profil d'installation « boutique-en-ligne » qui comprendrait ubercart et tous les modules nécessaires pour réaliser une boutique en ligne. Le profil d'installation se charge principalement d'activer et de paramètrer vos module selon vos instructions. Il vous suffit ensuite de faire une nouvelle installation de Drupal, de copier coller dans un dossier votre nouveau profil d'installation dans le répertoire profil, et de sélectionner le profil «boutique-en-ligne » à la place du profil « drupal ». Le profil d'installation peut surement faire très bon ménage avec le module features :-)

• module patterns : pas testé

• module deployment pas testé

Pour ma part, si je m'intéresse plus particulièrement aux modules context et features; c'est qu'ils sont utilisés par la société Development Seed et que de ce fait leur avenir et leur maintenance me semble assez sûr.

Aller plus loin avec le module strongarm et le fichier .module de votre feature

Dans les articles précédents j’ai expliqué comme combiner le module Features et le module Context pour pouvoir exporter la configuration de vos modules en un seul module que vous pouvez activer et désactiver à votre guise. Toutefois certaines limites apparaissent rapidement. Et si je veux que mon type de contenu « article_sport » ait par défaut ses commentaires désactivés ? Et comment faire pour exporter la configuration des modules non supportés par Features pour le moment ? Sommes-nous condamnés à fabriquer des features avec «seulement» CCK, views, context, image cache ? Que nenni.

Tirer parti du fichier .module de votre feature

En exportant votre feature, vous obtenez un module Drupal en bonne et due forme, si bien qu’il contient comme il se doit un fichier .module. Par défaut ce fichier contient cette unique ligne (dans mon cas, la feature se nomme « pack_reservation_taxi » ).

Cette ligne se charge d’aller cherches les autres fichiers de votre module contenant toute la configuration des modules composant votre features sous forme de tableaux php. Mais au-delà de cette ligne, vous êtes libre d’écrire absolument tout ce que voulez comme code php, comme si il s’agissait d’un module Drupal normal. Lors de votre prochain export, votre code fera partie du fichier .module de votre feature ! Voilà qui ouvre de nouveaux horizons.

C’est donc l’endroit idéal pour vous livrer aux hooks en tout genre qui peuvent vous permettre d’aller plus loin dans les ajustements de votre feature et améliorer son exportabilité. On peut imaginer utiliser le hook_enable (qui se déclenche uniquement au moment de l’activation de votre module, et donc de votre feature dans ce cas) pour lancer une requête sql permettant d’ajuster dans la table system le poids d’un autre module de façon automatisée par exemple.

Mais en utilisant le module Strongarm, qui est utilisé sur l’intranet drupal « open atrium » vous pouvez aussi prendre très facilement le contrôle d’une partie très importante de Drupal : les réglages de base des formulaires de configuration de n’importe quel module.

Un peu de théorie : La table « variable » de Drupal

En vous rendant dans la base de données de votre installation Drupal avec phpmyadmin ou autre, vous pourrez constater la présence d’une table variable. Cette table joue un rôle majeur dans la configuration de vos modules -et donc de votre site. En effet, chaque fois que vous vous rendez dans un formulaire de configuration d’un module, quand vous appuyez sur le bouton enregistrer, c’est dans cette table que sont stockés vos changements. Autrement dit, si nous pouvions exporter dans notre feature certaines variables de cette table, ça nous permettrait de maîtriser la configuration par défaut de n’importe quel module Drupal possédant une page d’administration lors de l’activation de notre feature.

Le module strongarm

C’est très justement ce que se propose de faire le module Strongarm. Ce module ne propose pas d’interface utilisateur, c’est au développeur d’implémenter un hook permettant de spécifier la configuration qu’il souhaite pour tel ou tel module Drupal. Une place toute trouvée pour implémenter ce hook c’est le fichier .module de votre feature :-)
Voici un exemple concret de ce hook que j’ai implémenté dans ma feature « pack_reservation_taxi », pour laquelle je souhaitais que soient désactivés par défaut les commentaires sur deux types de contenus spécifiques. Je souhaitais également que le module « automatic node title » soit automatiquement configuré pour cacher le titre de ces types de contenus et les remplacer par des tokens de mon choix. Plutôt que de refaire cela à la main lors de l’import de ma feature, j’ai implémenté le hook_strongarm, (disponible une fois activé le module Strongarm).

Une fois ce hook implémenté, vous pourrez voir (après avoir vidé le cache de Drupal) sur les types de contenus choisis que les commentaires sont automatiquement forcés à « disabled ». De plus, le module Strongarm vous affiche un message vous indiquant que des champs de ce type de contenus sont « forcés » par Strongarm. Les boutons radios pour changer la configuration des commentaires apparaîtront dans un cadre de couleur et seront grisés : vous ne pouvez plus les changer. Toutefois en vous rendant dans la page de configuration du module Strongarm, vous pouvez décider qu’il reste possible d’overrider ces réglages, en dépit des ordres donnés par votre hook.

En utilisant à bon escient le fichier .module de notre feature et Strongarm, nous disposons donc d’un sérieux arsenal pour contrôler une grande partie de la configuration de vos modules avec peu d’efforts.

API des formulaires sur Drupal 6

Si vous êtes habitués au PHP procédural, comprendre comment fonctionne Drupal pour générer les formulaires et traiter leurs données peut être déstabilisant. Voici les deux principales choses dont vous ne devez plus vous préoccupez en utilisant l’API des formulaires de Drupal :

• rédiger le html de votre formulaire : Drupal génère lui même de A à Z le html d’un formulaire. Vous devez simplement lui précisez des informations des champs que vous désirez afficher (type, titre, valeur par défaut etc…) via un array().

• récupérer les données en utilisant $_POST, $_GET etc… : L’API des formulaires récupère les données et les rend accessibles dans la variable $form_state[‘values’] que vous verrez plus bas.

Gérer un formulaire dans Drupal va en fait se constituer en 4 grandes étapes :
1) Créer une fonction qui va définir les éléments que va contenir votre formulaire
2) Ecrire une fonction de validation des données (permettant par exemple de vérifier que le champ «numéro de téléphone» contient bien uniquement des chiffres)
3) Ecrire une fonction de soumission du formulaire, qui va nous permettre de faire quelque chose des données transmises par le formulaire : les enregistrer dans la base de données par exemple.
4) Afficher le formulaire ! La fonction drupal_get_form() va permettre de générer le html de notre formulaire et de l’afficher.

Voici un exemple de code d’un formulaire très simple. Pour cela j’ai crée un petit module afin de pouvoir afficher ce formulaire sur une page dédiée. Vous trouverez ce module d’exemple attaché à cette page en bas.

n’oubliez pas de vider le cache de Drupal pour que votre nouveau item de menu soit pris en compte ! Sinon votre page ne s’affichera pas.

API des formulaire : Theming d'un formulaire

Voir documentation sur l’API des formulaires http://drupalfr.org/node/8337

Nous avons vu précédemment que le html de notre formulaire est généré automatiquement par l’API des formulaires de Drupal. Mais comment faire si nous voulons justement controler la mise en forme html de nos éléments, le présenter par exemple en trois colonnes, chacune étant un div avec un titre ? La réponse est : en utilisant une fonction theme.

Ecrire une fonction de theme

Pour cela nous devons déclarer une nouvelle fonction chargé de mettre en forme notre formulaire. Dans notre exemple, la fonction générant notre formulaire s’appelle «mon_formulaire». Si nous créons une fonction nommée «theme_mon_formulaire», celle ci sera utilisée par le systeme de theme de Drupal pour mettre en forme notre formulaire d’exemple à la place de l’affichage par défaut.

Explications :
- La fonction drupal_render() est utilisée pour généré le html d’une partie de notre formulaire. drupal_render($form[‘submit’]) va générer automatiquement le code html pour notre bouton de soumission.
- Notez bien que à la fin nous faisons un drupal_render sur tout le formulaire afin d’être sur qu’aucun élément de notre formulaire n’a été oublié par notre fonction theme : on est ainsi sûr d’afficher tout ce que nous n’avons pas affiché manuellement par drupal_render() et également que les champs cachés dont Drupal a besoin pour traiter un formulaire seront eux aussi bien présents.

Déclarer à Drupal notre fonction theme !

Le code ci-dessus ne modifiera en aucune façon l’affichage de votre formulaire pour le moment. Drupal doit en effet savoir que cette fonction theme existe, la convention de nommage avec ‘theme_+nom_du_formulaire’ n’est pas suffisante sur Drupal 6. Drupal fonctionne avec un «registre de themes» (theme registry) : il s’agit de la liste de toutes les fonctions themes déclarées par les modules.

Il faut donc maintenant que nous informions Drupal de l’existence de notre fonction theme, et pour cela nous devons la déclarer au registre des themes via un hook dans notre module :

Un hook_theme peut contenir plusieurs themes, c’est pour cela qu’il est déclaré en tant que array.
Ici on indique l’existence d’un theme ‘mon_formulaire’, ce qui signifie que Drupal cherchera la fonction «theme_mon_formulaire» pour générer notre html.

Il faut enfin vider le cache de Drupal (site > configuration > performance > vider le cache) afin que drupal rescanne tous les modules pour reconstruire le registre de thèùes en prenant en compte notre nouvelle fonction.

Déclarer une fonction theme alternative pour un formulaire

Il existe une autre manière de déclarer quel fonction theme doit utiliser le formulaire : en la déclarant dans la fonction ‘mon_formulaire’ en ajoutant ceci :

il faudra ensuit également avertir le theme de registrer de l’existence de cette nouvelle fonction theme via notre hook theme qui ressemblera alors à ceci :

Après avoir vidé le cache, drupal cherchera la fonction theme_mon_formulaire_alternatif. Celle ci sera cherchée avant la fonction theme_mon_formulaire qui du coup ne sera pas utilisée, si ces deux fonctions themes co-existent.

Exemple de hook_form_alter et de theming

Le code ci-dessous est simplement un exemple concret de module pour altérer un formulaire et le themer de façon plus poussé que dans les exemples précédents.
Ici le module s’appelle «formulaire_tableau» : le but est simplement d’améliorer la présentation d’un formulaire produit (node/add/tableaux dans ce cas) pour la boutique en ligne ubercart : le formulaire de node étant étant déjà altéré par ubercart, taxonomie, CCK, le résultat final niveau présentation est catastrophique : ici je fais une restructuration complète du formulaire afin d’en controler totalement la présentation et de réordonner les champs de façon logique pour l’utilisateur final ; et également pour remplir de façon automatique le champ référence.

HTML, CSS, Jpeg, Gif, PNG,JavaScript...

La position habituelle est de considérer que la bande passante est libérée. Erreur !

La bande passante est plus maltraitée que jamais. 2 facteurs :

• la taille des fichiers,
• le nombre de fichiers.

La bande passante corrige facilement le problème posé par les fichiers lourds. Mais ces mêmes fichiers ont progressé en même temps que la bande passante.

Par contre, la bande passante a un impact limité sur le problème du nombre de fichiers. Pour chaque fichier nécessaire à l’affichage de votre page, un navigateur va émettre une requête HTTP GET. Ces requêtes seront chacunes traitées individuellement par le serveur.

Pour chaque requête, le serveur préparera un environnement
d’exécution (réservation mémoire, variables d’environnement, communication inter-processus, etc.) qu’il devra ensuite nettoyer pour permettre la réception de nouvelles requêtes. Ces temps de fonctionnement sont incompressibles. Quelle que soit la taille des informations, il existe toujours une durée minimum de traitement.

Cette durée de traitement a un impact important sur le transfert de petits fichiers.

Or, les pages web sont de plus en plus peuplées de fichiers :

• images de fond,
• images,
• scripts javascript,
• feuilles de styles CSS,
• objets Flash,
• applets Java,
• icône Favicon,
• …

Celles ou ceux qui m’auront suivi jusque là se seront sans doute posé la question : il s’agit d’une situation générale, en quoi cela concerne-t-il Drupal précisément ?

La solution que je vais présenter permet d’alléger les fichiers CSS dans un thème sous Drupal.

Prenons une page au hasard de Drupal.org : http://drupal.org/node/100748
(le sujet importe peu).

Une analyse des fichiers nécessaires à cette page donne les résultats suivants :

• 1 fichier html : 16,17 Kio,
• 9 feuilles CSS : 44,63
  Kio,
• 12 images de fond : 3,14 Kio,
• 4 images : 4,38 Kio.

Le tout nous donne 68,32 Kio pour 26 fichiers. Les feuilles de style représentent un tiers des fichiers téléchargés et 65% du volume total !

Modifier son thème

L’idée pour faire perdre du poids aux feuilles CSS est la suivante :

• regrouper tous les fichiers en un seul,
• supprimer tous les espaces, les retours chariots et les commentaires.

Réaliser ces opérations manuellement n’est ni pratique, ni maintenable. Mais elles peuvent être automatisées dans le cadre de votre thème.

Avec l’aide d’un script PHP, il est possible de réaliser ces opérations à la «volée».

Le script compress_css.php se trouve sur la page suivante et doit être copié dans le répertoire de votre thème.

Pour l’utiliser dans votre thème, éditer le fichier page.tpl.php et insérez le code suivant :

en lieu et place des print $head; et print $styles;

Le script PHP va lire tous les fichiers CSS inclus dans l’entête HTML (balise head), les réunir en un seul, supprimer les élements inutiles et insérer le code pour la nouvelle feuille de style.

Pour exemple, l’utilisation de ce script m’a permis de passer de 50 Kio de CSS à 35 Kio (environ 30% de gain). C’est très appréciable sachant que certains standards d’accessibilité (voir Opquast) recommendent d’avoir une page d’accueil pesant moins de 100 Kio tout compris.

Script compress_css.php

Le script ci-dessous doit être copié dans le répertoire de votre thème pour pouvoir être utilisé.

Le répertoire doit être en écriture pour Apache (généralement 0777) car la version compressé des CSS est écrit dans un fichier *.compress.css (afin de ne pas recompresser les fichiers à chaque fois)

Le script prend en compte le «hack IE», celui qui fonctionne avec les commentaires, de sorte que ces commentaires ne soient pas effacés.

Installer TinyMCE

Cette méthode n’est plus valable ! Tinymce est maintenant intégré via wysiwyg.

TinyMCE est un module permettant la mise en place d’un éditeur de contenu WYSIWYG. Grâce à lui il devient simple de mettre en page ses contenus, aussi simple que d’utiliser un traitement de texte.

1 La phase classique

• Téléchargez le module Drupal : http://drupal.org/project/tinymce

• Décompressez le

• Envoyez le via FTP dans votre Drupal, dans le répertoire /sites/all/modules où doivent être contenus les modules que vous installez.

2 La phase inhabituelle

• Téléchargez le moteur de TinyMCE chez Moxie : http://tinymce.moxiecode.com/download.php

• Décompressez le évidement

• Envoyez le dans votre module TinyMCE créé lors de la phase 1.
  Ce qui vous donnera un chemin comme : /sites/all/modules/tinymce/tinymce

3 Activation

• Dans votre interface d’administration de votre site allez dans la construction des modules et activez Tiny

• Allez ensuite dans la gestion des utilisateurs et éditez les rôles utilisateurs afin qu’ils puissent se servir de Tiny

• Dans la configuration du site faites un tour dans TinyMCE et créez un profil d’utilisation, n’oubliez pas de l’attribuer aux rôles désirés.

• Lors de la création de ce profil, dans «Basic Setup» passez «Default state» en true afin d’activer l’affichage par défaut de Tiny.

• N’oubliez pas que Tiny met en page grâce aux balises HTML, pour que ce que vos contenus s’affichent tel que désiré le format d’entrée contenus doit être en Full HTML. Pour paramétrer cela par défaut allez dans Administrer > Configuration du site > Formats d’entrée et cochez Full HTML pour que ce format soit fixé automatiquement lors de la création d’un contenu.
  D’autre part tous vos contenus créés avant cette modification concerveront leur format d’entrée initial. Il vous faudra donc éditer chaque contenu de ce type pour qu’il accepte le Full HTML.

4 Francisation

• Téléchargez le pack contenant la traduction francophone ; http://tinymce.moxiecode.com/language.php

• Décompressez la chose vous aurez alors les fichiers de traductions classés selon la même hierachisation que votre «sous-module»

• Prennez votre mal en patience et envoyez chaque petit fichier dans le répertoire correspondant.
  La tâche est longue, ennuyeuse et si vous faites une erreur d’innatention vous êtes bon pour tout recommencer.

• Retournez dans la configuration de TinyMCE via l’administration de Drupal, éditez le profil de sorte que dans «Basic Setup» ce soit le français qui soit activé.

5 Boostez TinyMCE

Un outil supplémentaire permet de «compresser» Tiny et de le rendre plus rapide. Il s’agit de TinyMCE compressor.
ATTENTION : il se peut que cet ajout pose des problèmes sur certaines configurations (disparition de la barre d’outils, cf les nombreux posts plus bas), testez d’abord Tiny sans le compresseur pour vérifier que tout fonctionne correctement, installez le ensuite, si vous rencontrez des problèmes virez le.

• Téléchargez TinyMCE compressor PHP ici : http://tinymce.moxiecode.com/download.php

• Décompressez et envoyez dans /sites/all/modules/tinymce/tinymce/jscripts/tiny_mce

6 Régler d’éventuels problèmes de lisibilité (facultatif)

Tout est correctement installé mais votre interface texte de Tiny est toute noire et vous ne parvenez pas à lire ce que vous écrivez dans de telles circonstances…
C’est que Tiny se sert du fond de votre site comme fond de zone de saisie. Pas de panique, allez dans Administrer > Configuration du site > TinyMCE. Éditez les profils pour que dans «CSS» le champ «Editor CSS» l’apparence sélectionnez soit «tinyMCE default».
Sauvez les modifications et le problème est résolu.

Enjoy ! ;)

Ajouter le support de BBcode à votre site

BBcode est un langage de balise simplifié qui permet de mettre en forme du texte et qui n’autorise pas l’exécution de scripts, ce qui en fait un langage de choix pour la publication de contenu sur les sites web.

Drupal ne propose pas le support de bbcode par défaut, mais il existe un module qui permet de combler cette lacune. Nous allons voir comment le mettre en oeuvre.

1. La première chose à faire est de télécharger le module bbcode. Le module est ici :
   http://drupal.org/project/bbcode
2. Décompressez l’archive, puis copiez le répertoire bbcode dans le répertoire module de votre installation de drupal. Ensuite rendez vous dans Administrer/module pour activez le module bbcode.
3. A présent, bbcode est bien installé, mais il faut encore le configurer. En effet le module bbcode agis comme un filtre d’entrée et va convertir le code bbcode en balises html. Il nous faut donc créer un format d’entrée. Rendez vous dans Administrer/Configuration du site/Formats d’entrée, créez un nouveau format nommé BBcode puis validez.
4. Ensuite cliquez sur le bouton Configurer sur la ligne du format BBcode. La page qui s’affiche liste les différents filtres disponibles et vous devriez voir apparaître la ligne bbcode. Sélectionnez donc le filtre bbcode ainsi que Line break converter puis sauvez vos changements.
5. cliquez sur le bouton Réordonner sur la ligne du format BBcode. La page qui s’affiche liste les filtres utilisés dans ce format d’entrée. BBcode doit être en bas de la liste sous «filtre HTML».
6. Il ne reste plus qu’à ajuster les permissions pour ce nouveau format. Il est souvent judicieux de mettre le format BBcode comme format par défaut, et de n’autoriser les autres formats qu’aux administrateurs.

Comment faire ?

Un collection de tutoriels détaillant la réalisation avec drupal d’un besoin précis.

Comprendre le cache de page

(je n’ai pas vérifié si ces informations étaient également valables pour les versions 5 et 6. Je ne pense cependant pas qu’il y ait de gros écarts)

Drupal dispose d’un mécanisme de cache évolué (mise en mémoire d’informations précédemment calculées). Tellement évolué qu’il n’est pas toujours évident d’en comprendre le fonctionnement.

Il faut tout d’abord distinguer 2 niveaux :

• le cache,
• le cache de page.

N’importe quel module peut utiliser le cache pour son propre usage au moyen des fonctions cache_set et cache_get. N’importe quel type de données peut être stocké dans le cache, que ce soit du code HTML, du XML ou encore des données binaires. Tout module effectuant des calculs ou des requêtes complexes peut tirer parti de ces fonctions.

Le cache de page travaille au niveau supérieur : c’est carrément la page entière et ses entêtes HTTP (headers) qui sont stockées.

Notes :

• Les pages sont cachées selon l’URI. Si vous utilisez les alias, node/78 et alias/vers/node/78 seront cachées indépendamment bien qu’il s’agisse de la même page,
• Le mécanisme de cache de page est complètement désactivé si l’utilisateur est identifié (mais pas le mécanisme de cache standard).
• La table cache de Drupal peut être vidée sans hésitation puisque, par définition, toutes ses données seront recalculées à la volée.
• Les pages contenant des formulaires ne sont pas gênées par le cache de page car les données sont transmises par méthode POST et chaque message en attente empêche l’utilisation du cache.
• Les informations mises à jour depuis le Cron ne seront disponibles aux utilisateurs anonymes qu’après écoulement de la durée de vie minimum dans le cas du cache de page.

La page admin/settings permet d’activer ou désactiver le cache de page et d’indiquer la durée de vie minimum d’un élément du cache. Ces deux paramètres ne sont pas liés directement. La durée de vie minimum est utilisée même si le cache de page est désactivé puisque le cache de page n’est qu’une utilisation particulière du cache de Drupal.

Cette durée indique le temps pendant lequel Drupal conservera un objet dans le cache. Tant que cette durée ne se sera pas écoulée, l’objet sera resservi. Si l’objet est redemandé au-delà de cette durée de vie, il sera recalculé.

Gestion des menus avec drupal 4.7

But : obtenir une hiérarchie de pages accessibles via les liens primaires.

Prenons l’exemple ci dessous :

Nous y voyons en haut un menu contenant 5 liens qui sont : Accueil, L’association, Projets, Liens, Contacts. Le menu utilisé est celui appelé Primary links ou Liens Primaires en Français. Grâce à cela nous auront la possibilité d’afficher notre menu dans le thème de notre site.

Premier exemple : le lien Accueil

Le lien Accueil pointe tout simplement sur la page d’accueil. Pour le créer, nous allons dans administrer/menu, puis on va cliquer sur ajouter un élément de menu

On se retrouve alors avec le formulaire suivant :

• Titre : le titre de notre élément (dans notre exemple «Accueil»)
• Description : texte affiché grâce à une bulle d’aide lors du passage de la souris au dessus du lien
• Chemin : le chemin vers lequel le lien pointera (dans notre exemple <front> renvoi vers la page d’accueil)
• Elément parent : informe de l’endroit où notre lien sera mis. Nous souhaitons qu’il soit dans le menu «Primary Links»
• Poids : permet de définir l’ordre d’apparition des éléments du menu. Dans l’exemple les éléments Accueil, L’association, Projets, Liens et Contacts sont tous contenu directement dans Primary links (ils ont tous le même parent). Le poids permet donc de définir l’ordre dans lequel ils doivent apparaître. Dans le cas contraire, l’ordre alphabétique est privilégié

Il ne nous reste plus qu’à cliquer sur le bouton Soumettre

L’élément Contact à été crée de la même manière. Nous avons mis Contact dans le champ «Titre» et contact dans le champ «Chemin» (le formulaire de contact est habituellement accessible via l’URL http://monsite.com/?q=contact)

Deuxième exemple : l’élément L’association

L’élément L’association est une page crée avec drupal et que l’on va ancrer dans le menu Primary links. Pour cela allons dans créer un contenu/page Nous nous retrouvons alors avec le formulaire classique de création de contenu que nous allons remplir de manière classique. Nous allons aussi nous intéressé au bloc Paramètres de menu (cliquez sur le lien pour ouvrir le bloc si ce n’est pas déjà fait). Et là, ho surprise nous retrouvons exactement le même formulaire que dans notre premier exemple.

• Titre : L’association
• Description : Le Mans Sans Fil
• Elément parent : Primary links
• Poids : 1 (nous voulons que le liens s’affiche après «Accueil» qui a un poids de 0)

Les éléments Projets et Liens ont été crée de la même manière. Nous obtenons donc le menu suivant :

Troisième exemple : les éléments de second niveau (ou sous-menus)

Nous allons crée une nouvelle page comme précédemment, nous rendre ensuite dans le bloc Paramètres de menu, mettre le titre, la description, et choisir comme Elément parent L’association

Et voilà ! nous avons notre premier sous-menu. Nous pouvons faire de même avec d’autres pages, ou même encore faire des sous-sous-menus…