planete drupalfr -

Partie II – Plus loin dans le référencement

admin — Fri, 12 Mar 2010 13:36:48 +0000

Ce que nous venons de faire était simple mais pourtant ces actions étaient essentielles. Maintenant nous allons aller un petit peu plus loin et passer à des choses plus marrantes.

XML sitemaps

La création d’un site map ou en français d’un plan de site va permettre d’indiquer facilement aux moteurs de recherche le contenu qu’il leur est possible d’explorer sur notre site.

Un Site map est une cartographie d’adresses des différents contenus qui composent votre site Internet auxquels on ajoute des informations, de précieuses méta-données.

Pour réaliser un site map facilement vous pouvez utiliser les modules Site map ou XML site map qui ont été conçu pour répondre aux spécifications de sitemaps.org.

Mettre en place un sitemap sur votre site.
Modules requis : site map ou xml site map

Robots txt

Lorsqu’un moteur de recherche analyse votre site web on dit que celui-ci indexe votre contenu, ce robot d’indexation est appelé Crawler (« Butineurs »). Il fonctionne comme un internaute, il navigue de lien en lien, analyse le contenu et indexe les mots clés qu’il rencontre dans le but de capitaliser le plus de page web possible.

Afin de préciser au Crawler ce qu’il doit ou ce qu’il n’a pas le droit d’indexer on utilise un fichier nommé Robot.txt contenant des règles d’autorisation ou d’exclusion. Ce fichier est la première chose lue par le moteur d’indexation lors de son passage sur votre site. Si toutefois vous n’aviez pas de fichier Robots.txt sur votre site, le Crawler considèrera qu’il peut analyser tout le contenu de votre site.

Notez que dans l’archive de Drupal que vous avez téléchargée, il y a déja un fichier Robots.txt

Pour plus de renseignements sur la configuration du fichier je vous renvoie sur wikipédia et sur annuaire-info pour quelques exemples.

Avec Drupal il y a un module pour presque tout, alors il existe un module pour gérer le fichier robots.txt depuis l’interface d’administration, mais notez que ce module est surtout utile dans le cas de gestion de multi-site ou vous auriez un fichier par site.

Global redirect

Dans la premiere partie de cet article nous avons mis en place les « belles urls » afin d’avoir des urls de type http://monsite.fr/drupal-référencement. A ce stade nous nous retrouvons avec un problème de duplication de contenu. En effet Drupal ne desactive pas l’ancienne adresse et le contenu devient accessible par deux adresses.
Cet action est dangeureuse, Google n’aime pas ça et il assigne cela à de la multiplication artificielle de contenu qu’il punit en inscrivant votre site à sa liste noire.

Pour éliminer ce problème nous allons utiliser le module global redirect qui, au moment de l’accès à une page, interrompera le chargement de celle-ci et redirigera vers l’alias de la page.

L’administration du module se fait depuis la page [ Admin › configuration du site › globalredirect ] mais la configuration par défaut est parfaite.

Modules requis : global redirect

Path redirect

Le nom de ce module parle de lui même. Path redirect permet de rediriger des urls vers un autre chemin interne ou externe. Ce qui est pratique lorsque votre contenu a bougé ou que vous souhaitez détourner le trafic vers une autre page.

Pour créer une redirection c’est très simple, il vous suffit de vous rendre sur la page dédiée : [ Admin › construction du site › urls redirigées ] d’insérer l’ancienne adresse, la nouvelle adresse et les variables à passer avec l’url.

Vous pouvez depuis le menu ‘Paramètres’ choisir d’informer l’internaute qu’il subit une redirection vers une autre page.

Modules requis : Path redirect

Search 404

Lorsque vous essayez d’accéder à un contenu inexistant ou que l’adresse url à changé Drupal vous affiche une page d’erreur, c’est la fameuse page 404.

Le module seach 404 va nous permettre d’aller plus loin dans l’aide aux internautes puisqu’il permet lorsqu’une page est introuvable d’exécuter une recherche en fonction de la demande initiale.

Prenez par exemple la page http://monsite.fr/does/not/exist, search 404 va effectuer une recherche sur la phrase « does not exist ».

L’administration du module [ Admin › configuration du site › Search 404 settings ] permet de modifier le comportement du module lorsqu’il trouve une réponse pour rediriger l’internaute. Vous pouvez ainsi choisir de forcer l’utilisateur à être redirigé vers la première réponse. Je déconseille fortement d’activer cette option, car vos utilisateurs risquent de ne pas comprendre comment et pourquoi ils sont arrivés à cet endroit.

Modules requis : Search 404

Vous êtes maintenant bien préparé pour mener votre combat au référencement. Mais installer des modules n’est pas suffisant, il faut aussi surveiller et optimiser ce qui à été fait. Pour cela rendez-vous dans la troisième partie ou nous aborderons ce sujet qui vous donnera quelques pistes à étudier.

module Display Suite

admin — Thu, 11 Mar 2010 19:02:11 +0000

Une superbe démonstration du module Display Suite. Ce module ressemble à un Panels appliqué à la node : il permet de construire des "layouts de node" en arrangeant à sa guise les champs CCK présents ... A module à explorer.

module drupal : WYSIWYG

admin — Thu, 11 Mar 2010 16:59:05 +0000

Une petite démonstration en image du module WYSIWYG qui va vous permettre d'installer des éditeurs wysiwyg externes sur votre champ
Body ou autres champs CCK textarea ...

en lire plus

node reference

admin — Thu, 11 Mar 2010 16:26:46 +0000

Dans cette vidéo, Bob Christensen nous montre un exemple d'utilisation du champ CCK "Node reference" (fourni par defaut avec CCK).
Grâce à l'utilisation des modules Node Reference URL Widget et Views attach, l'utilisateur pourra ajouter automatiquement des contenus "relatifs" à un article principal. Les contributions s'affichent ensuite en dessous de l'article principal à l'aide de Views attach. Un peu complexe à comprendre, mais très intéressant comme approche ... à tester.

Webdev | Aldebaran Robotics

Drupal Groupe France — Wed, 10 Mar 2010 15:38:33 +0000

Webdev

Aldebaran Robotics

Employment type:
Full time

Telecommute:
Not allowed

Aldebaran Robotics vend ses robots partout dans le monde et le web est notre principal outil de communication vers l’extérieur.
Composé de plusieurs sites dédiés, le déploiement web a besoin d’une sérieuse mise à niveau : entre le site grand public difficile à maintenir, des sites dédiés obsolètes et la volonté d’offrir de nouveaux services en ligne, le travail ne manque pas !

Encadré par l’équipe communication, vous aurez la charge de tous ces développements et serez force de proposition sur les améliorations possibles de l’ensemble du déploiement.

Profil recherché
Développeur web souple, maitrisant différents langages et CMS, vous saurez vous adapter aux contraintes de visibilité et de gestion de communauté, en proposant des solutions adaptées.

Compétences requises
 Rigoureux, autonome et énergique
 Maitrise de Drupal et de Joomla
 Très bonnes compétences en css, html, Javascript et PHP
 Des compétences en Flash et autres technologies sont un plus.

Poste à pourvoir immédiatement
Poste basé à Paris.

parent@aldebaran-robotics.com

http://www.aldebaran-robotics.com

Fichier attachéTaille

_MG_4365.jpg116.05 Ko

France

Drupal côté jardin

admin — Tue, 09 Mar 2010 17:06:40 +0000

Bonjour,

Il y a peu j'ai reçu mon invitation pour tester Drupal Gardens. Comme le savent déjà nos plus fidèles lecteurs, Gardens est une initiative de la société Acquia, et consiste en une offre hébergée de Drupal 7. Comme sur Wordpress.com où en quelques instants vous créez votre blog Wordpress, Gardens permet d'installer facilement puis de paramétrer (moins facilement) un site Drupal.

Stage Développement | G-Nova

Drupal Groupe France — Tue, 09 Mar 2010 11:04:37 +0000

G-Nova

Stage Développement

Employment type:
Full time

Employment type:
Part time

Telecommute:
Not allowed

G-Nova, agence Nantaise dynamique en web-marketing cherche jeunes motards du web habitués aux arsouilles PHP/MySQL de 2 ans et +. La maîtrise de Drupal dans sa version 6 cylindres est vivement appréciée afin de s’intégrer rapidement à la bande.

L’esprit Libre est un pré-requis tout comme la culture de l’open-source. L’implication dans la communauté Drupal est un plus.

Vous n’hésitez pas à crier “Gaz !”, à relever les nouveaux défis et enrouler courbes après courbes, alors ce poste est fait pour vous !

Cette offre s'adresse à tout type de stage (alternance, stages, fin d'études etc) et n'est pas limitée dans le temps.

http://www.g-nova.fr

Rennes / Bretagne

Créer et appliquer un patch pour un module sous Linux

admin — Mon, 08 Mar 2010 12:44:45 +0000

Il est parfois inévitable de devoir modifier un module contribué afin d’étendre les possibilités de celui-ci ou tout simplement pour corriger quelque chose.
Dans tous les cas il ne faut pas modifier les fichiers du module et les mettre sur votre site parce qu’à ce moment il vous sera compliqué de mettre à jour votre module. Imaginez le jour ou vous voudrez appliquer la nouvelle version de celui-ci, toutes vos modifications seront écrasées.

Pour modifier correctement un module vous devez créer un patch que vous appliquerez par la suite au module original.

Dans un premier temps nous allons voir comment générer notre patch puis comment l’appliquer. Il existe plusieurs façons pour faire cela. La solution que je vous propose n’est qu’une solution parmi tant d’autres.

Comme exemple j’ai pris la fonction facebook_status_activity() du module facebook_status ci-dessous. Cette fonction permet, lorsque le module activity est installé, d’insérer des activités lorsqu’un utilisateur a mis à jour son statut.

Avant tout, nous allons créer une copie de notre fichier que nous allons nommer facebook_status.origine.module et qui sera notre version de référence pour effectuer notre comparaison.

Maintenant nous allons pouvoir apporter toutes nos modifications au fichier facebook_status.module. Dans notre cas nous allons ajouter une nouvelle entrée au tableau data, qui contiendra l’id du statut.

'status-id' => $status->sid.

1. Repérer les différences avec la commande diff

A ce stade nous avons nos deux fichiers, l’original et le modifié. La commande diff va nous permettre de voir la différence entre les deux fichiers :

$ diff facebook_status.module.origine facebook_status.module
1558a1559
> 'status-id' => $status->sid,

La comparaison entre la version originale et la nouvelle version nous indique qu’entre la ligne 1558 et 1559 une différence a été trouvée. Ici c’est une nouvelle ligne qui a été insérée, on peut le voir grâce au symbôle ‘>’. Dans le cas d’une suppression le symbôle aurait été ‘<’.

La commande diff permet également de connaître les différences entre les fichiers de deux répertoires. Pour cela, il suffit d’ajouter le paramètre -r à la commande :

diff -r facebook_status.module facebook_status_origine.module

2. Créer le fichier de patch

Nous allons maintenant créer un fichier contenant cette modification que l’on pourra appliquer facilement par la suite. Nous allons réutiliser la fonction diff avec l’option -u qui en plus de notre différence va nous donner les 3 lignes avant et après notre modification.

$ diff -u facebook_status.module.origine facebook_status.module > facebook_status.module.patch
$ cat facebook_status.module.patch
--- facebook_status.module.origine 2010-03-04 15:47:47.000000000 +0100
+++ facebook_status.module 2010-03-01 14:16:47.000000000 +0100
@@ -1556,6 +1556,7 @@
$data = array(
'owner' => theme('username', $owner),
'poster' => theme('username', $poster),
+ 'status-id' => $status->sid,
'status-unformatted' => check_plain($status->status),
'status-themed' => theme('facebook_status_item', $status),
'status_time' => $status->status_time,

Les différences trouvées ont été enregistrées dans un fichier nommé facebook_status.module.patch.

3. Patcher avec la commande patch

Maintenant que nous avons un fichier patch exploitable nous allons pouvoir l’appliquer à la version originale de notre fichier. Vous pouvez supprimer le fichier facebook_status.module et renommer le fichier facebook_status.module.origine en facebook_status.module afin que les choses retournent à leur état initial ou tout simplement retélécharger le module.

Pour mettre à jour notre fichier, rendez vous dans le repertoire du fichier à patcher et utilisez la commande patch :

$ patch < facebook_status.module.patch
patching file facebook_status.module

Votre fichier est maintenant patché, vous pouvez l’ouvrir pour visualiser les modifications.

Drupal 7 Code Sprint Montreal

Echo Bravo — Fri, 05 Mar 2010 17:38:16 +0000

La communauté montréalaise se réunit pour faire avancer Drupal 7

La communauté Drupal montréalaise s'est réunie le 19 février pour apporter sa contribution à la tâche monumentale qu'est la publication de la nouvelle mouture de Drupal. Comme vous le savez peut-être, il s'agit d'un effort entièrement collaboratif, puisque que contrairement aux logiciels publiés en entreprise, Drupal est entièrement rédigé par sa communauté, sur une base volontaire.

Modifier les emails envoyés depuis votre site.

admin — Mon, 01 Mar 2010 12:40:59 +0000

Pour compléter mon précendent billet voici comment modifier les emails envoyés depuis votre site.

Pour générer l’envoi de mail depuis un module nous avons utilisé les fonctions hook_mail() et drupal_mail(). Pour la modification nous allons utiliser la fonction hook_mail_alter(&$message) afin d’avoir un accès complet à tous les emails envoyés.

La variable $message contient toutes les informations nécessaires à l’envoi de l’email et à ce stade, l’email à été formaté et est prêt à l’envoi. Dans cette variable on retrouve donc les infos headers, le body, le sujet, les paramètres passés lors de la génération de l’email et surtout l’identifiant renseigné.

C’est grâce à ce dernier que nous allons pouvoir identifier et modifier un email en particulier. Cette clé est constituée des deux prermiers paramètres fusionnés passés à la fonction drupal_mail, soit dans notre cas MyModule et envoi_email.
Voici un exemple pour ajouter la signature de votre site au bas de notre email.

function MyOtherModule_mail_alter(&$message) {
if ($message['id'] == 'MyModule_envoi_email') {
$message['body'] .= "--\nMail envoyé depuis " . variable_get('sitename', t('Drupal'));
}
}

$message['body'] est un tableau, vous pouvez donc lui rajouter autant d’entrées que vous voulez

Edit : Suite à mes échanges avec Opi sur mon impossibilité à passer un tableau à la variable $message['body'] j’ai cherché ce qu’il se passait. En fait, entre la déclaration de mon e-mail et la modification de celui-ci, le module htmlmail qui était installé sur mon drupal transformait le tableau en une chaîne de caractères :/
Si vous subissez le même problème, il suffit de modifier le poids de vos modules pour qu’ils s’exécutent dans l’ordre voulu.

Articles relatifs : Envoyer des emails depuis un module

Représenter Drupal à la solution linux du 16 au 18 mars

Drupal Groupe France — Fri, 26 Feb 2010 14:04:17 +0000

Start:
2010-03-16 09:00 - 2010-03-18 18:00 UTC

Organizers:

JBI

cravalec

User group meeting

Bonjour,

Voulez vous présenter Drupal au salon solutions Linux ? 12 000 visiteurs en 2009 encore plus attendu en 2010...

Si vous voulez être présent sur le stand ou simplement recevoir une invitation merci de compléter le formulaire en ligne. https://spreadsheets.google.com/viewform?formkey=dHVrbVlIWkNMbXVKMkJ4Vmd...

Si vous voulez nous donner un exemple de vos dernière réalisation Drupal : merci de m’envoyer un mail ingold . jb (a) gmail . com

Bien cordialement.

Jean-Baptiste Ingold
06 24 78 29 22

PS Si vous êtes présents signalez nous en commentaire.

Quelques chiffres sur le salon http://www.solutionslinux.fr :

• 150 000 invitations

• 40 000 programmes de conférences

• 420 000 e-mailings

• une Campagne SMS

• 12 000 Direct-badges aux pré-enregistrés 2009

• + de 7 000 badges VIP envoyés aux décideurs grands comptes

• suivi des visiteurs pré-enregistrés à J-15, J-8, J-2 et le jour J

• une large couverture médiatique grâce à des partenariats forts : avec les fédérations, les associations professionnelles et les médias.

France

Koumbit implique la communauté Drupal pour le premier code sprint Drupal 7 de Montréal

Koumbit — Fri, 26 Feb 2010 02:37:03 +0000

C'est dans une ambiance conviviale, agrémentée de snacks, de rafraîchissements, de bières et de pizzas gratuits que Koumbit a reçu, vendredi dernier, les volontaires du premier Code Sprint Drupal 7 de Montréal. En tout, une dizaine de travailleurs payés par Koumbit et près d'une vingtaine d'invités, des particuliers et des représentants d'autres compagnies montréalaises, ont joint leurs efforts pour faire avancer le développement, la traduction et la documentation de la prochaine version de Drupal. Nous espérons que le succès de cette expérience encouragera d'autres firmes à réaménager leur espace de travail, le temps d'une journée, pour accommoder de nouveaux volontaires lors des prochains sprints, qu'ils aient lieu à Montréal ou ailleurs dans le monde.

Les événements Drupal locaux sont toujours une plaisante opportunité de rencontrer d'autres membres de la communauté et d'échanger autour d'intérêts communs. Les « code sprints » sont particulièrement enrichissants car ils permettent aux participants de mettre leur tête dans le code et d'apporter des améliorations concrètes. Ces sprints sont aussi une occasion inestimable de diffuser un savoir-faire qui favorise une meilleure appropriation de Drupal, des outils et des pratiques qui supportent le projet. Cette collaboration entre compétiteurs fortifie autant ses contributeurs que le produit qu'elle cultive. Elle rend chacun mieux apte à s'impliquer.

Le coup de départ de cette journée, donné par Angie Byron (alias webchick) en matinée, a amené l'ensemble des volontaires à se diviser en groupes ciblés selon leurs centres d'intérêts : résolution de problèmes du noyau Drupal 7, ajustements du côté client, documentation des changements aux APIs, traduction vers le français et appropriation des outils de tests unitaires. Au fil de la journée, plusieurs d'entre eux ont varié leurs défis; certains ont révisé de nouveaux thèmes proposés pour Drupal 7 et d'autres se sont penchés sur le processus de mise à jour de Drupal 6 vers Drupal 7. En tout, près d'une trentaine de problèmes abordés ont été notés par notre équipe. Plusieurs d'entre eux peuvent être retracés sur drupal.org grâce à l'étiquette #d7csmtl.

Au-delà du résultat concret obtenu au terme de cette journée, nous espérons que cet effort aura su motiver de nouveaux contributeurs à s'impliquer dans le développement de Drupal 7. Nous pensons que de tels événements aident à consolider la communauté Drupal montréalaise et à maintenir son effervescence. Koumbit est fier d'avoir provoqué le mouvement. Ce n'est donc pas sans un soupçon de défi que nous souhaitons que le succès de ce code sprint saura en inspirer d'autres à répéter l'expérience.

Premiers clics sous OpenAtrium 1-BETA4

admin — Mon, 22 Feb 2010 13:35:36 +0000

1. Introduction

Development Seed vient de passer sa plateforme collaborative basée sur Drupal 6 à la version 1.0-BETA4. Des chiffres, des lettres, une beta de plus... Oui, mais pas n’importe quelle beta !

Outre la modification du thème avec ré-agencement des boutons, fil d’ariane, logo, diminution de la taille du header et bien d’autres permettant une visibilité accrue, la principale attente de cette nouvelle béta-mouture se trouve dans l’utilisation des versions 3.x des modules spaces et context, 2.x pour le module Admin et la suppression de FeedsAPI par Feeds.

Nous allons faire un premier état des lieux en explorant le potentiel des nouvelles fonctionnalités ainsi que l’ergonomie de l'interface disponibles juste après une installation basique (utilisation des modules activés par défaut uniquement).

en lire plus

Installer OpenAtrium sous MAMP

admin — Sun, 21 Feb 2010 11:26:05 +0000

1. Introduction

Avec la sortie de OpenAtrium 1.0-beta4, j'ai bien entendu voulu le tester et ainsi pouvoir voir les améliorations apportées par rapport à la version précédente.

Travaillant depuis peu sous Mac, j'ai installé MAMP pour pouvoir faire mes tests rapidement en local (peut-être n'est-ce pas la meilleure solution pour développer sous mac, je reste ouvert à toute proposition).

Premier tour de roue, installation de drush et drush_make pour pouvoir suivre les étapes de l'installation fournies par Development Seed : http://openatrium.com/node/35.

en lire plus

Drupal.org ni Bazaar ni Subversif, mais sûrement GIT

arNuméral — Mon, 15 Feb 2010 19:12:13 +0000

Ceci étant dit, rien n'est encore fait, mais il semblerait que nous en prenions clairement le chemin.

Pour une part, il est clair que CVS peut être considéré à juste titre comme un gestionnaire de version pour le peu archaïque. Et il ne faut pas s'en étonner, ce système a tout de même plus de 20 ans !

Pour revenir à nos moutons, nous étions beaucoup à nous demander quand drupal.org se déciderait à basculer le dépôt des modules contribution (et du core) sur quelque chose de plus moderne, comme au hasard, subversion. Manque de bol, la grande mode des gestionnaires de version distribués est passée par là, et subversion nous est passé sous le nez au profit de GIT.

Alors qu'est-ce qu'un gestionnaire de version décentralisé ? Disons pour faire (très) simple que la grosse différence avec un centralisé est que sur votre machine, vous ne disposez plus d'une copie de travail, mais d'un dépôt local complet et opérationnel qui sait communiquer son état à des dépôts distants. Cela commence par récupérer d'un dépôt distant (pull), pour y travailler comme d'habitude (commit, update, etc.) et éventuellement, si vous avez les droits, remonter vos modifications sur un dépôt distant (push) qui peut être le même que celui du pull, ou un autre...

La gestion décentralisée de version permet donc à chacun, y compris de petites équipes, de travailler sur les sources d'un projet tout en laissant à d'autre le choix d'intégrer ou pas les modifications au sein du projet central. C'est en quelque sorte la notion de fork généralisé. Ce concept est très intéressant pour permettre à toute une communauté de s'exprimer sur des projets d'envergure comme le noyau Linux, ou dans une moindre mesure, Drupal Core. C'est d'ailleurs Torvald, après une saga autour du gestionnaire de version propriétaire BitKeeper, qui a écrit les premières moutures de GIT. Mais malgré ce que peut dire Torvald, les centralisés ne sont pas pour autant mort, et continuent à répondre à 99.9% des besoins d'équipe de 1 à 10 personnes bossant sur de plus modestes projets. Et le revamping de CVS, subversion, rentre parfaitement dans ce cadre.

Entendons nous bien, je n'ai absolument rien contre ce type de gestionnaire, et encore moins contre GIT que j'envisage d'adopter pour mes propres projets. Mais autant je peux comprendre ce choix dans le cas du core de Drupal, autant pour la myriade de modules contribs, maintenus à grand peine par de petits développeurs dans leur coin (dont je fais parti) qui n'ont pas que cela à foutre de jongler d'un gestionnaire à l'autre. Et si l'on met ceci en perspective du fait que l'adoption massive de Subversion en entreprise est enfin concrétisée, GIT un choix que je trouve un peu... lourd.

D'autant plus lourd que ce produit, comme son concept de base, est très jeune. Cela veut dire apprendre un nouveau mode de fonctionnement pour ceux qui ont déjà eu du mal à passer à SVN, mais cela implique aussi une maturité plus faible sur des plate-formes comme eclipse (qui est aussi la base de Zend Studio). Alors que Subversive arrive enfin à des performances et une stabilité potables, voilà que l'on se retrouve avec EGit, un plugin qui n'en finit pas d'incuber, aux fonctionnalités pour le moins anémiques (pas de vue "dépôt" par exemple), et à la stabilité "hasardeuse" (régulièrement, un menu "team" déserté de toute fonction, le dossier .git visible dans l'arbo, etc). Alors on peut tout gérer en ligne de commande hein, c'est pas moi que ça va gêner, ou alors utiliser un "machin" comme tortoise, mais cela continue de me laisser dans l'idée que ce choix est un tantinet "geek".

Le (délicat) problème des images dans Drupal

admin — Mon, 15 Feb 2010 10:41:13 +0000

Vous avez sans doute déjà été confronté, dans votre découverte de Drupal, à une question aussi bête que « comment puis-je mettre des images dans mon site ». Cette question en recouvre plusieurs : comment insérer une image dans un texte, comment organiser les images chargées, comment réaliser un album … ? Toutes questions qui, dans Drupal, n’ont aucune réponse simple, au risque d’impatienter les débutants.

Drupal 7 : avis et retour d'expérience

Narno — Wed, 10 Feb 2010 22:21:37 +0000

Drupal 7 est toujours en cours de développement (ou plutôt en cours de finition), néanmoins une version alpha à été publiée : l'occasion idéale de faire joujou avec la prochaine mouture de Drupal.

Je pense que nombreux sont ceux qui attendent cette nouvelle version, très prometteuse, tout particulièrement en terme d'ergonomie et d'interface utilisateur.

A défaut de rédiger un billet critique basée sur mes essais de la version alpha (je manque de courage et de temps), j'ai compilé quelques articles et billets traitant du sujet :

Drupal 7, les nouveautés : Yoran, par anticipation (juin 2009) annonçait les nouveautés que nous réservait la version 7 de Drupal, avec quelques hypothétiques qui ont on trouvées réponse depuis. Billet plutôt complet pour l'époque et critique.
Drupal 7, quoi de neuf à l’horizon ? : billet de Julien Dubois (très à l'aise avec le CMS) décrivant les nouveautés de Drupal 7.
À l'aube de Drupal 7 : billet un peu austère (blog d'entreprise) mais qui remet bien en contexte les choix fonctionnels et techniques à l'origine de la version 7 de Drupal.
J'ai (rapidement) testé pour vous... Drupal 7 : retour d'expérience à chaud de Marie-Hélène, juste après la sortie de la version alpha 1. Point de vue intéressant, partagé par la plupart de testeur de cette version alpha (dont moi). Lire les commentaires.
Drupal 7 et l’accessibilité : l'accessibiliét étant l'un des objectifs de D7, il aurait été dommage de ne pas en parler !
Howto install Drupal 7 : comment installer la beta 1 en ligne de commande (en français, malgré le titre anglophone).

J'espère qu'après avoir lu ces différents billets vous aurez envie d'essayer la dernière version de Dupal ! :-)

Liens pratiques :

Télécharger Drupal (liste des versions)
Participer à la traduction de Drupal 7

Mon guide Drupal (5) : régler les droits d’accès et finaliser un site Drupal

Lektum.info — Mon, 01 Feb 2010 10:00:26 +0000

À partir de mes différentes lectures et expériences, je vous propose dans cet article un tutoriel synthétique pour comprendre comment bien régler les droits dans Drupal et ne rien oublier d’important avant la mise en production finale. Cet article est le 5ème d’une série consacrée aux différentes étapes de la mise en oeuvre d’un site [...]

DrupalForFirebug - Debugger Drupal avec Firebug

admin — Sat, 23 Jan 2010 11:53:25 +0000

1. Présentation de DrupalForFirebug

Lors du développement de sites sous Drupal, il est souvent nécessaires à un moment donné d'obtenir des informations sur des variables maisons ou gérées par Drupal. A titre indicatif, les plus courantes sont $node ou $form.

DrupalForFirebug permet donc d'afficher dans Firebug le contenu de variables par l'intermédiaire d'une méthode firep() et donne en tout temps le contenu des variables courantes drupal : $form, $node, $view, requêtes sql.

Nous allons voir dans un premier temps comment installer le module puis les fonctionnalités disponibles.

en lire plus

J'ai (rapidement) testé pour vous... Drupal 7

admin — Fri, 15 Jan 2010 19:11:32 +0000

Voilà ! comme prévu depuis plusieurs jours, la première version "alpha" de Drupal 7 est sortie tout à l'heure. Difficile de faire un compte-rendu qui n'ait pas l'air d'un "catalogue de ce qui a changé", mais je vais essayer de vous faire une petite synthèse de ce que j'ai vu. Naturellement chacun retient les points qui correspondent à ses besoins et attentes donc ce que j'ai apprécié peut vous paraître un détail et vous pouvez vous être focalisé sur autre chose (car le mieux pour vous faire votre idée est de le télécharger vous-même).

Enfin!

drupalfr.org — Mon, 11 Jan 2010 00:43:56 +0000

Environ 23 mois après la sortie de Drupal 6, 13 mois après la sortie de Views 2.0 et CCK 2.0 et environ 10 mois après Drupal.org, nous avons le plaisir de vous annoncer que Drupalfr.org tourne maintenant sous Drupal 6 !

Cette mise à jour, longuement attendue (et constamment reportée), a été effectuée il y a environ une heure, sans encombres (ou presque). Le site est pour l'instant quasiment identique au précedent, à l'exception de quelques améliorations que vous découvrirez au fil de votre navigation, et probablement de nouveaux bugs que je vous invite à nous signaler en commentaire de ce billet.

Cette base enfin mise à jour va surtout nous permettre de conduire, au fil des prochains mois, d'importantes modifications et améliorations. Pour cela, nous avons besoin de vous.

Plusieurs idées de modifications ont été proposées. Elles doivent murir dans cette page de wiki, et être priorisées. Une fois un accord trouvé, nous avons besoins de volontaires pour implémenter ces modifications. L'avantage, c'est que nous pouvons maintenant utiliser ces choses modernes (ImageCache, Features, etc.) afin de nous simplifier la vie. En outre, nous avons maintenant un thème de base propre basé sur Ninesixty.

Avis aux volontaires !

Créer des templates (fichier.tpl.php) pour themer vos modules

admin — Mon, 04 Jan 2010 09:10:56 +0000

Lors de la création de vos modules vous pouvez être amenés à mettre en forme votre contenu pour garder une approche cohérence avec la dissociation fond / forme. Il est donc nécessaire de donner la possibilité au themer de pouvoir modifier la mise en forme du contenu que vous aller afficher.
Afin de rendre une telle action possible, vous allez devoir déclarer au sein de votre module un hook_theme, qui va déclarer les éléments qui pourront être themés via vos templates.
Le hook_theme est simplement constitué d’un tableau d’éléments skinnables avec pour chaque entrée une clé « template» qui correspond au nom du fichier .tpl.php utilisé pour le theme et une clé « arguments» correspondant à un tableau de paramètres à passer à la fonction de theme().

function hook_theme() {
return array(
'my_themeable_call' => array(
'template' => 'gabarit.tpl.php',
'arguments' => array("param1" => NULL),
),
);
}

A noter : Le « .tpl.php» est facultatif car toujours suggéré par le moteur de template et il est recommandé d’utiliser le même nom comme clé et comme nom de fichier pour le template. (Les noms sont ici différents pour vous permettre de décortiquer la mécanique). [Merci Cyril pour la remarque]

Voilà votre fonction de thème déclarée, il ne reste plus qu’à l’utiliser.
Prenons l’exemple d’un bloc, vous souhaitez utiliser votre fonction de thème dans son contenu, il vous suffit d’utiliser dans le contenu du bloc (cf hook_block) votre fonction de theme : $bloc['content'] = theme(’my_themeable_call’, $param1);
De cette façon vous enverrez à votre fichier de template la variable $param1 (pouvant contenir tout type de données). Si vous omettez de passer un argument, la valeur par défaut déclarée dans le hook_theme sera utilisée (dans notre exemple si j’omets $param1, sa valeur sera NULL).

Plaçons-nous maintenant dans notre fichier de template gabarit.tpl.php, c’est le fichier que votre themer pourra surcharger en le copiant collant dans le dossier de son thème.
Les variables à disposition sont celles que vous avez passé en paramètres lors de l’appel de la fonction de thème (ici $param1) et les éventuelles variables ajoutées par les fonctions de preprocess. (La signature de la fonction est template_preprocess_my_themeable_call, surchargeable par THEME_preprocess_my_themeable_call).

De cette façon vous pouvez donc créer vos propres fichiers de theming lors de la publication de vos modules afin de vous faire adorer par les themers !

Créer des handlers de menu

arNuméral — Mon, 21 Dec 2009 10:07:33 +0000

Tout drupalien sait ce qu'est un "élément de menu" : un machin qui se colle dans un... menu, et qui apparaît quelque part sur l'interface graphique pour permettre l'affichage d'une page. Ces éléments de menu sont généralement crées à la mano en passant par le backoffice, via la section Construction du site puis Menus. Là on peut ajouter des associations entre un chemin valide et un titre de lien.

Ce "chemin valide" est systématiquement fournit par l'un des modules activé (ex. user/login issu modules/user). Mais alors comment créer ses propres chemins liés à ses propres pages ou actions, sans passer par d'inutile (pour cela) usines à gaz comme Panel ou Views ?

Le but de ce tutoriel est de démystifier ce passage obligé de la vie d'un module.

Les sources

L'ensemble des sources de ce tutoriel est disponible ici. Il s'agit d'un serveur Subversion, donc vous pouvez aussi directement récupérer les sources dans votre dossier site/all/modules par la commande suivante :

gaston$cd /var/www/drupal/site/all/modulesgaston$mkdir tutorielsgaston$cd tutorielsgaston$svn co http://www.arnumeral.fr/subversion/public/tutoriels_drupal/tutoriel_menus...gaston$

Cycle de vie d'un requete

Lorsqu'apache reçoit une requête, par exemple http://mon_site/mon-super-article, il commence par ré-écrire la partie "chemin" de l'URL de sorte à la rendre assimilable par Drupal. C'est le fameux système d'URL simplifiées (clean UEL). L'URL devient alors http://mon_site/index.php?q=mon-super-article, index.php étant le point d'entrée de Drupal.

La partie ?q=mon-super-article est donc une variable $_GET['q'] que va recevoir drupal pour effectuer une action. La première étape pour résoudre ce chemin, est de déterminer si le contenu de $_GET['q'] ne serait pas hasard pas un alias en cherchant une correspondance dans la table url_alias. L'exemple est bien choisi, il en trouvera un qui sera node/666. mon-super-article est donc le chemin, et node/666 le chemin dit "interne", celui que va réellement prendre en charge un module.

Et c'est effectivement la seconde étape de Drupal, trouver quel module est en charge du chemin interne node/666. Plus exactement, et attention il va y avoir risque de confusion de vocabulaire, Drupal va chercher quel "menu" est associé à ce chemin. Pour ne pas entretenir la confusion trop longtemps, un "menu" pour les modules, est une association entre un chemin interne (ici node/666), et un module (ici, le module modules/node). Pour simplifier le discours, j'appellerais cela un menu handler pour le différencier des éléments de menu qui eux, associent un lien à un chemin interne.

Si aucun handler n'est trouvé, Drupal renvoie le fameux 404 fichier non trouve. Si le handler existe bien mais que l'utilisateur qui cherche à le déclencher n'a pas les droits pour cela, il renverra un 401 Access denied. Enfin si le handler existe et que l'utilisateur a les droits, Drupal va transférer le traitement à une des fonctions du module qui a déclaré ce handler.

Cette fonction, appelée callback a plusieurs possibilités. Si le chemin interne correspond à une page (c'est le cas de node/666), la fonction callback va renvoyer, par son return, une chaîne de caractère qui correspondra au coeur de page (région content). Drupal va alors récupérer cette chaîne, la faire passer dans le thème, et ainsi produire la page correspondant au chemin interne. C'est ainsi que l'article http://mon_site/mon-super-article sera affiché.

Autre cas de figure, le chemin interne n'est pas une page, mais une action comme par exemple node/666/delete (suppression d'un article). Dans ce cas, la fonction callback n'a aucune raison de renvoyer une chaîne de caractère. Elle va simplement supprimer l'article, et terminer, sans return par un drupal_goto pour rediriger une un chemin interne d'atterrissage.

Enfin, dernier cas un peu moins usité, le chemin interne doit renvoyer des données, par exemple du code XML pour une procédure AJAX. Dans ce cas le code sera imprimé (print ou echo) directement dans la fonction de callback, qui se terminera par un très brutal exit();, coupant ainsi la chique à Drupal.

Implémentation de hook_menu

Maintenant que le sujet est un peu dégrossi, voyons comment faire déclarer un handler par un module. Pour commencer, il nous faut un construire un module de base (voir ce tutoriel) dans lequel nous allons implémenter un hook_menu. Ce hook permet à Drupal de récupérer l'ensemble des handlers de menu publiés par un module donné et son implémentation ressemble à ceci :

function tutoriel_menus_menu() {
$items = array ();

$items['tutoriels/menus/simple'] = array (
'title' => 'Un menu simple',
'description' => "Ceci est un menu simple",
'page callback' => 'tutoriel_menus_simple_menu_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
)
);

return $items;
}

implémentation d'un hook_menu

Chaque handler déclaré par le hook_menu est une entrée pour un tableau qui sera renvoyé en retour de la fonction. La clef utilisée par ce tableau est le chemin interne pris en charge par le handler, et sa valeur, une structure le décrivant. Dans cette structure nous avons des éléments simples à comprendre comme title ou description qui permettrons à Drupal de créer un élément de menu à partir de ce handler. Notez que ces deux chaînes ne doivent pas utiliser la fonction de traduction t(...).

Déclaration de la callback

page callback est l'élément fondamental de ce handler. Il s'agit de la fonction qui va être appelée par Drupal pour effectuer l'action associée au chemin interne. Le paramètre file définit quant à lui dans quel fichier PHP cette fonction se trouve. Cette astuce a permis à Drupal 6 d'améliorer grandement ses performances par rapport à Drupal 5. En effet, file permet de ne charger que les fichiers PHP utiles au traitement d'un chemin, sans charger tout le reste.

Si le paramètre file est omis (ce qui n'est pas conseillé), Drupal cherchera la fonction parmi celles déjà chargée en mémoire. Si ce paramètre est présent, le fichier correspondant sera cherché dans le dossier du module (utilisez le paramètre file path si le fichier se trouve hors de ce dossier). D'une manière général, les callbacks correspondant à des pages sont rangées dans un fichier mon_module.pages.inc. Celles correspondant à l'administration dans mon_module.admin.inc, etc.

Droits associés au handler

Le dernier paramètre, access argument, contient un tableau de permissions nécessaires à l'accès au menu. Ici access content désigne le droit d'accéder au contenu, ce que tout le monde peut généralement faire. Mais par exemple pour limiter aux seuls administrateur, nous aurions pu mettre administer site configuration.

Ce paramètre access argument est en réalité utilisé conjointement avec le paramètre access callback. Mais lorsque ce dernier est omis, Drupal utilise par défaut la valeur user_access. Ainsi vous comprenez que ces deux paramètres correspondent en réalité à un appel à la fonction user_access(array('access content')) qui renvoie vrai si l'utilisateur courant a les droits demandés. A titre d'exemple, vous auriez pu aussi utiliser pour access callback les fonctions is_anonymous_user ou user_is_logged_in, toute deux fournies par le module user. Comme elles ne prennent pas de paramètre, le paramètre access arguments peut dans ce cas être omis.

D'une manière générale, vous pouvez utiliser la fonction qui vous chante pour gérer les droits, pour peu qu'elle renvoie true si l'utilisateur est valide et false dans le cas contraire.

Implémentation de la callback

Il ne nous reste maintenant plus qu'à implémenter la callback, en commençant par créer un fichier tutoriel_menu.pages.inc et y placer une fonction comme celle-ci :

function tutoriel_menus_simple_menu_callback() {
$output="Coeur de page associé à ce modeste menu";
return $output;
}

tutoriel_menus.pages.inc - callback générique

Bon, un peu simpliste comme rendu, mais c'est juste pour l'exemple. Vous pouvez mettre dans $output tout ce qui vous chante, de simple messages à des tableaux triables.

Vidange du cache de menus

Il ne nous reste maintenant plus qu'à tester cela. Attention cependant, ce hook n'est, pour des raisons de performances, invoqué qu'à l'activation du module. C'est très bien pour la première fois, mais moins drôle lors des essais suivants. Pour régler ce problème, je vous conseille d'installer le module administration menu qui dans son menu déroulant de droite, dispose d'une action de vidange du cache des menus.

Une fois le module activé, vous devriez voir apparaître dans votre menu Navigation, le nouveau menu Un menu simple. En l'activant, dans le coeur de page, doit apparaître le retour de notre callback.

Des éléments menus arborescents

Il est possible de prolonger l'exemple précédent en créant une cascade de menu. Basiquement, une telle arborescence consiste simplement à créer un menu par niveau de chemin. Dans le chapitre précédent, le chemin était tutoriels/menus/simple. Pour rendre visible les deux niveaux précédents, il nous font donc créer deux menus respectivement pour tutoriels, puis tutoriels/menus.

$items['tutoriels'] = array (
'title' => 'Les tutoriels',
'page callback' => 'tutoriel_menus_tutoriels_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'expanded'=>true
);

$items['tutoriels/menus'] = array (
'title' => 'Les menus',
'description' => t("Tutoriel sur les menus"),
'page callback' => 'tutoriel_menus_tutoriels_menu_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'expanded'=>true
);

Ajout de deux niveaux de menu

Notez la propriété expanded qui permettent d'auto-déployer les deux niveaux pour que tout soit visible par défaut. Enfin, comme nous utilisons deux nouvelles callback, il faut aussi les ajouter dans tutoriel_menu.pages.inc

function tutoriel_menus_tutoriels_callback() {
return "Les tutoriels";
}

function tutoriel_menus_tutoriels_menus_callback() {
return "Les tutoriels des menus";
}

Ajout des deux callback

Il suffit maintenant de reconstruire les menus et d'observer le résultat.

Choix du menu cible

Par défaut, nos éléments de menu sont intégrés par Drupal dans le menu administration si le chemin commence par admin/..., ou dans le menu navigation le cas échéant. Il est cependant possible d'ajouter nos handlers ailleurs en utilisant la propriété menu_name. Pour illustrer cette possibilité, nous allons ajouter aux liens primaires (un menu généralement affiché en haut à droite de chaque page), l'élément de menu A propos de nous :

$items['informations'] = array (
'title' => 'A propos de nous',
'page callback' => 'tutoriel_menus_a_propos_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'menu_name' => 'primary-links'
);

Ajout d'un élément de menu dans le menu 'liens primaires'

Comme toujours, il nous faut une nouvelle callback :

function tutoriel_menus_a_propos_callback() {
return "Bla bla bla...";
}

Callback pour l'élément de menu 'information'

Une fois le cache des menus reconstruit, si vous allez dans l'administration des menus, sur le menu Liens primaires, vous devriez voir apparaître le nouvel élément de menu. Et si votre thème l'affiche par défaut en haut à droite de la page, il y sera directement visible.

L'astuce ici consiste à savoir que le nom interne du menu liens primaires est primary-links. En utilisant ce nom pour la propriété menu_name, nous avons forcé l'ajout de ces menus aux liens primaires. Notez que c'est un ajout totalement dynamique, au sens où les menus ainsi créés disparaîtront d'eux même à la prochaine reconstruction des menus si vous les supprimez de votre hook. En somme une alternative intelligente pour déployer facilement des menus en production sans avoir à se refrapper une configuration manuelle, par exemple pour instancier toutes les sections d'un site sur le menu "liens secondaires".

Les onglets

Une autre manière de gérer les menus arborescents est de les afficher sous la forme d'onglet. Drupal permet en effet de gérer ainsi deux niveaux d'onglets (vous en avez un exemple dans la configuration d'un thème). Ces onglets sont très faciles à mettre en oeuvre pour peu d'en comprendre la logique.

$items['tutoriels/menus/simple/onglet-1'] = array (
'title' => 'Onglet 1',
'type' => MENU_DEFAULT_LOCAL_TASK,
'access arguments' => array (
'access content'
)
);

$items['tutoriels/menus/simple/onglet-2'] = array (
'type' => MENU_LOCAL_TASK,
'title' => 'Onglet 2',
'page callback' => 'tutoriel_menus_onglet2_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
)
);

$items['tutoriels/menus/simple/onglet-2/onglet-2-1'] = array (
'title' => 'Onglet 2.1',
'access arguments' => array (
'access content'
),
'type' => MENU_DEFAULT_LOCAL_TASK
);

$items['tutoriels/menus/simple/onglet-2/onglet-2-2'] = array (
'title' => 'Onglet 2.2',
'page callback' => 'tutoriel_menus_onglet22_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'type' => MENU_LOCAL_TASK
);

Ajout d'onglets

Comme vous le voyez, nous sommes ici proche des menus arborescents. La nouveauté est tout d'abord l'utilisation du paramètre type indiquant à Drupal que nous définissons ici des onglets (appelés Tasks, ou tâches). MENU_LOCAL_TASK marque un onglet normal et MENU_DEFAULT_LOCAL_TASK marque l'onglet par défaut pour un niveau. Notez l'absence de callback pour les handlers marqués MENU_DEFAULT_LOCAL_TASK. En effet, la règle est que chaque niveau d'onglet doit disposer d'un MENU_DEFAULT_LOCAL_TASK, et que ce handler est automatiquement au chemin interne de son handler parent. En d'autres termes, si vous cliquez sur Onglet 1, c'est le chemin de notre menu simple qui s'affiche et son handler qui est utilisé. De même en cliquant sur Onglet 2.1, c'est le handler et donc le chemin et la callback de l'onglet 2 qui est utilisé. Du coup, nous n'avons que deux callback à ajouter

function tutoriel_menus_onglet2_callback() {
return "Contenu de l'onglet 2";
}

function tutoriel_menus_onglet22_callback() {
return "Contenu de l'onglet 22";
}

Callbacks pour les onglets

Les handlers \"cachés\"

Comme nous l'avons vu plus haut, nous fabriquons dans notre module des handlers de menu, et non des éléments de menus. Si jusqu'à maintenant nous avions une création automatique d'éléments de menu pour chacun de nos handlers, c'est soit que nous ométions le paramétrage type, qui a pour valeur par défaut MENU_NORMAL_ITEM (comprendre "un handler pour lequel drupal doit créer un élément de menu"), ou que nous voulions afficher des onglets avec MENU_LOCAL_TASK et MENU_DEFAULT_LOCAL_TASK.

Maintenant, dans de nombreux cas nos modules n'ont aucun besoin d'éléments de menu mais juste une URL associée à une page et/ou une action. C'est par exemple le cas si nous voulons créer une action d'ajout, ou dans l'exemple qui suit, un simple Hello World.

$items['tutoriels/menus/hello'] = array (
'page callback' => 'tutoriel_menus_hello_callback',
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'type'=>MENU_CALLBACK
);

Ajout d'un handler sans élément de menu

Et comme toujours, nous ajoutons la fonction callback associée

function tutoriel_menus_hello_callback() {
return "Hello World";
}

Callback du handler sans élément de menu

Une fois le cache de menu reconstruit, vous constaterez que cette fois, aucun élément de menu n'a été rajouté par Drupal. Pour utiliser ce handler, il nous faut directement taper son URL (ou chemin interne) directement dans la zone d'adresse du navigateur, soit http://mon_site/tutoriels/menus/hello.

Les seules différences avec les handlers que nous avons créé jusqu'à maintenant sont que nous n'avons fournit à Drupal ni titre, ni description, et que nous avons en revanche spécifié MENU_CALLBACK comme paramètre type. Ce type permet juste de dire à Drupal qu'il n'est pas utile de cherche à créer un élément de menu.

Handlers paramétrés

Ce type de handler sans élément de menu est très utile pour créer des actions comme "ajouter", "supprimer", etc. Encore faut il pouvoir fournir des paramètres à ce menu de sorte à pouvoir indiquer, dans l'URL, la référence de l'objet à détruire.

Depuis la version 6, Drupal dispose d'un système très bien fait pour passer des paramètres au handler, basé sur le caractère %. Ainsi si nous ajoutons le menu suivant :

$items['tutoriels/menus/hello1/%'] = array (
'page callback' => 'tutoriel_menus_hello1_callback',
'page arguments' => array(3),
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'type'=>MENU_CALLBACK
);

Ajout d'un handler paramétré

Et que nous ajoutons la callback suivante :

function tutoriel_menus_hello1_callback($message) {
return "Hello $message";
}

Ajout d'une callback paramétrée

Après reconstruction du menu, nous constatons que l'URL http://mon_site/tutoriels/menus/hello1/gaston provoque l'affichage du message Hello gaston. Pour comprendre ce qui se passe, retournons sur la déclaration de notre handler.

D'abord, nous avons dans le chemin interne un symbole % qui indique à Drupal que cet élément de chemin est un paramètre et peut donc prendre n'importe quelle valeur (ici gaston). Ensuite nous avons un nouveau paramètre page arguments contenant un tableau. Le contenu de ce tableau sera transmis à la callback. Si un de ses éléments est un chiffre, il sera préalablement par l'élément de chemin de rang correspondant (qui commence à . Si l'élément du tableau n'est pas un chiffre, il sera transmis tel-quel à la fonction.

Dans le cas de notre chemin, nous demandons à Drupal de placer en seul paramètre de la callback l'élément de chemin de rang 3 (c'est à dire le 4ième). C'est pour cela que notre callback dispose d'un paramètre $message qui recevra cette valeur.

Il est possible d'avoir plusieurs paramètres à la callback dont l'ordre et le type sera spécifié par page arguments. Mais plus intéressant encore, il est aussi possible de passer en paramètre des objets préchargés par Drupal. Pour tester cela, ajoutons encore un nouvel handler et sa callback :

$items['tutoriels/menus/hello2/%user'] = array (
'page callback' => 'tutoriel_menus_hello2_callback',
'page arguments' => array(3),
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'type'=>MENU_CALLBACK
);

// callback associée à mettre dans tutoriel_menus.pages.inc
function tutoriel_menus_hello2_callback($user) {
return "Hello {$user->name}";
}

Ajout d'un handler paramétré avec objet

Reconstruisons le cache des menus et lançons l'URL http://mon_site/tutoriels/menus/hello2/1. Vous devriez alors voir apparaître un Hello administrateur (ou n'importe quel nom que vous aurez utilisé comme administrateur de votre site).

L'astuce ici tient à l'utilisation non plus du simple %, mais de %user. Ce dernier indique à Drupal de "charger en mémoire l'utilisateur aillant pour ID l'élément de chemin donné dans l'URL". C'est ainsi que notre callback hérite d'un objet $user chargé à partir de l'ID 1 (celui de l'administrateur).

Il est intéressant de comprendre comment le "magie" fonctionne ici. Lorsque Drupal rencontre un paramètre de handler de la forme %objet, il va chercher une fonction pré-existante de la forme objet_load. S'il la trouve (ici c'est le cas, il s'agit de user_load), il lui passe en paramètre l'élément de chemin (ici 1) correspondant. Les fonctions objet_load renvoient toujours l'objet chargé à partir du paramètre (ici $user=user_load(1)), et c'est cet objet qui est utilisé comme paramètre à la callback.

En standard, Drupal dispose de plusieurs fonctions de type objet_load. Citons par exemple node_load qui par un %node permet de passer un contenu en paramètre d'une callback.

Mais vous pouvez aussi créer la votre. En effet, si vous utilisez un élément de chemin %mon_objet comme ceci

$items['tutoriels/menus/hello3/%mon_objet'] = array (
'page callback' => 'tutoriel_menus_hello3_callback',
'page arguments' => array(3),
'file' => 'tutoriel_menus.pages.inc',
'access arguments' => array (
'access content'
),
'type'=>MENU_CALLBACK
);

// callback associée à mettre dans tutoriel_menus.pages.inc
function tutoriel_menus_hello3_callback($mon_objet) {
return "Hello {$mon_objet['name']}";
}

Utilisation d'un chargeur custom

Vous devez en outre ajouter une fonction de type object_load pour que Drupal puisse faire correspondre le paramètre de rang 3, à l'argument %mon_objet :

function mon_objet_load($id) {
return array('name'=>"Objet[$id]");
}

Chargeur custom

Vous n'avez maintenant plus qu'à reconstruire les menus et tester http://mon_site/tutoriels/menus/hello3/12 pour voir apparaître "Hello Objet[12]".

Conclusion

Voilà, fin du "petit" tour d'horizon sur les menus. Comme vous l'avez vu, le sujet est pour le peu dense, à la mesure de la richesse du sujet. Ceci étant dit, nous n'avons ici qu'abordé l'essentiel, il reste encore beaucoup de choses à découvrir en explorant l'API des menus.

Drupal 6.15 and 5.21

drupalfr.org — Thu, 17 Dec 2009 20:52:06 +0000

Drupal a été mis à jour afin de corriger de multiples vulnérabilités qualifiées de "non critiques" (SA-CORE-2009-009). Il est tout de même conseillé de mettre vos installations à jours.

Téléchargement :

Koumbit était l'hôte de la rencontre Drupal de décembre à Montréal

Koumbit — Thu, 10 Dec 2009 16:16:41 +0000

Merci à tous ceux qui se sont rendus à nos bureaux pour la dernière rencontre Drupal. C'est toujours plaisant de se retrouver en bonne compagnie pour discuter des grands événements Drupal à venir. Ce vendredi, nous avons reçu la présence notable d'Angie Byron, co-mainteneur de Drupal 7. Elle nous a présenté le projet Coder pour faciliter la migration des modules des versions précédentes vers Drupal 7. Le module Coder devient rapidement un outil incontournable. Koumbit s'en sert d'ailleurs pour migrer les modules désuets de Drupal 5.x vers une version, plus courante, de Drupal 6.x. Cette fois-ci, nous nous en sommes servi pour appliquer des correctifs au noyau de Drupal 7, que la communauté Drupal attend avec impatience.

La communauté Drupal de Montréal est en pleine effervescence, et Koumbit est heureux de s'impliquer! Pour ne pas passer à côté de la prochaine rencontre, nous vous invitons à suivre le groupe Montreal-Quebec sur groups.drupal.org ou à vous inscrire à la page Facebook de Koumbit.