planete drupalfr -

Nouveau livre sur Drupal... en français !

Drupal Groupe France — Thu, 02 Sep 2010 16:05:12 +0000

Bonjour à tous,
je me permets de publier une info :

Un nouveau livre sur Drupal en Français devrait paraître le 11 octobre 2010.

DRUPAL - Réalisez des développements professionnels avec PHP

détails : ...

Editions : ENI
Collection : Expert IT
Auteurs : David Olmeta - Rémi Benoit (AddVista).
En volume : 400 pages + la version numérique du livre papier offerte jusqu'au 31/12/10.
Versions : D6 et D7 (d'après les tags de la fiche)
Niveau : confirmé à expert.
Téléchargement de fichiers liés à l’ouvrage : oui
Etude de cas : oui
Prix : n.c
Date de parution : 11/10/10
Fiche de présentation principale du livre : http://bit.ly/bX7C6T

a+ ;-)

@drupalgrenoble

France

Un aixois sur Paris - Drink & Drupal sur Paris le vendredi 10 septembre

Drupal Groupe France — Thu, 02 Sep 2010 09:09:13 +0000

Start:
2010-09-10 18:00 - 20:00 Europe/Paris

User group meeting

Organizers:

Guillaume Bec

N'étant plus parisien, j'ai maintenant le droit de lancer des Drink & Drupal à l'arrache lors de mon passage à la capitale.

Et donc c'est lancé, je serais sur Paris le vendredi 10 septembre pour boire un coup à partir de 18h et ça sera au Frog & Rosbif

Pour rappel un Drink & Drupal c'est juste un coup à boire ! Pas de présentation, pas d'internet, juste l'occasion de se retrouver, de discuter avec un drupalien de passage autour d'une petite mousse.

France

Drupal Meetup Paris - 14 septembre

Drupal Groupe France — Wed, 01 Sep 2010 16:23:58 +0000

Start:
2010-09-14 18:30 - 20:00 Europe/Paris

User group meeting

Organizers:

smokinggoat

JulienD

Salut tout le monde!

Prenez note de la date du premier rencontre Drupal de la rentrée! Quel que soit votre niveau ou votre utilisation de Drupal vous êtes les bienvenus.

Comme d'habitude, locale (à Paris) et contenu à définir, mais nous aurons comme d'habitude une présentation et une série de Lightning Talks.

N'hésitez pas à vous inscrire et à participer à l'événement ou de me proposer des preso / talks.

DRUPAL MEETUP
mardi 18h30 - 20h00
14 septembre, 2010
(Locale a définir...)

France

How To: Using Drupal Twitter Module

admin — Sun, 22 Aug 2010 18:13:07 +0000

Une démonstration en vidéo du module Twitterpar Matt Petrowsky.
Une autre démo de ce module est disponible ici : Twitter module

Voir la vidéo (19 min) :

Infos :

Le .mov (Quicktime) : TwitterModule_d6.mov
Article original de l'auteur : How To: Using Drupal Twitter Module

How To: Enhance Drupal's user access, features & control

admin — Sun, 22 Aug 2010 16:29:39 +0000

Une démonstration par Matt Petrowsky des modules :
modr8 (module qui
permet de mettre certains types de contenus en "File d'attente pour Modération", comme cela existe pour
les commentaires, excellent !)
Vertical Tabs
(un module très connu qui améliore l'interface du "formulaire de création de contenus" ...)
Override Node
Options (module qui permet de donner certains permissions sur des éléments du formulaire
de création de contenu, très utile dans certains cas).

Voir la vidéo (17 min) :

Infos :

Le .mov (Quicktime) : Drupal-User-Features_d6.mov
Article original de l'auteur : How To: Enhance Drupal's user access, features & control

Questions...

admin — Sun, 22 Aug 2010 16:16:36 +0000

Salut !

En cette fin de beau week-end du mois d'août, alors que vient de s'ouvrir la DrupalCon Copenhague (où je ne suis pas), toute la Drupalie bruisse de questions plus angoissantes les unes que les autres :

- Drupal 7 sera-t-il utilisable avant Noël ?

- Que va dire Dries dans sa keynote d'ouverture ?

- Maintenant qu'il est à Copenhague, Damien Tournoud pourra-t-il en repartir ?

A vrai dire, la seule question qui m'inquiète, pour le moment, c'est de savoir si j'aurai le temps de préparer un petit quelque chose pour marquer le premier anniversaire de Drupalistic (eeeh oui le temps passe ma bonne dame)

Mais je promets de ne pas vous laisser, sur le reste, dans une si insoutenable détresse, et de vous rendre compte de la situation dès que Damien aura remis les pieds à Paris (ahahah, astuce, comment gagner du temps : avec un peu de chance, ça me laisse une bonne trentaine d'heures de plus que n'importe qui d'autre)... Héhéhé :-) !

Bonne semaine aux Danois, bon courage, tenez-nous au courant et revenez vaillants !

en lire plus

Questions...

admin — Sun, 22 Aug 2010 16:16:36 +0000

Salut !

- Drupal 7 sera-t-il utilisable avant Noël ?

- Que va dire Dries dans sa keynote d'ouverture ?

- Maintenant qu'il est à Copenhague, Damien Tournoud pourra-t-il en repartir ?

Bonne semaine aux Danois, bon courage, tenez-nous au courant et revenez vaillants !

en lire plus

How To: Manage Drupal Permissions More Easily

admin — Sun, 22 Aug 2010 15:51:05 +0000

Une démonstration par Matt Petrowsky des modules Filter Permissions, Permissions Lock et Better Permissions qui vont vous permettre d'améliorer la gestion des permissions dans Drupal; surtout si vous avez de nombreux roles et modules d'installé...

Voir la vidéo (21 min) :

Infos :

Le .mov (Quicktime) : Managing-Drupal-Permissions_d6.mov
Article original de l'auteur : How To: Manage Drupal Permissions More Easily

Retour sur la rencontre Drupal Montréal

Echo Bravo — Tue, 17 Aug 2010 19:02:48 +0000

Le 12 août dernier, Whisky Echo Bravo recevait passionnés et curieux pour échanger à propos de Drupal

Nous remercions tout ceux qui ce sont déplacés pour la rencontre du 12 août. Nous avons grandement apprécié votre participation aux discussions portant sur le développement de thèmes, la gestion de sites multilingues et l'importation de données dans Drupal.

Ajouter une étape de confirmation à vos formulaires

admin — Mon, 09 Aug 2010 11:09:16 +0000

C’est une petite fonctionnalité dont vous pourriez avoir besoin, voici une présentation du fonctionnement d’une telle fonctionnalité.
A première vue cela peut sembler très facile à implémenter mais au final ça ne l’est pas tant que ça.

Prenons l’exemple d’un formulaire qui permet de clore des votes sur des sessions, cette action étant importante nous allons ajouter une étape de confirmation avant de faire le traitement.

Je simplifie volontairement le formulaire que l’on créé, résumons le à un simple bouton d’action :

<?php
/**
* Form to close votes on sessions.
*/
function feature_conference_close_sessions_form(&$form_state) {
$form['submit'] = array(
'#type' => 'submit',
'#value' => t('Clore les votes'),
);
return $form;
}
?>

Ensuite dans le traitement de ce formulaire il faut faire une redirection vers le formulaire de confirmation. Aucun traitement ne doit être fait ici sachant que le formulaire n’a pas encore été confirmé par l’utilisateur.

<?php
/**
* Redirect to confirmation form.
*/
function feature_conference_close_sessions_form_submit($form, &$form_state) {
$form_state['redirect'] = 'sessions/close/confirm';
}
?>

Sachant que nous faisons une redirection vers une entrée de menu, il faut la déclarer via un hook_menu().

<?php
/**
* Implement hook_menu().
*/
function feature_conference_menu() {
return array(
'sessions/close/confirm' => array(
'page callback' => 'drupal_get_form',
'page arguments' => array('feature_conference_close_sessions_confirm_form'),
'access callback' => TRUE,
),
}
?>

Dans ce formulaire il vous faut utiliser la fonction confirm_form() (http://api.drupal.org/api/function/confirm_form/6) pour obtenir la page de confirmation.

<?php
/**
* Confirmation form before closing sessions.
*/
function feature_conference_close_sessions_confirm_form(&$form_state) {
$form = array();
$desc = "Les votes ne seront plus possibles.";
return confirm_form($form, "Êtes-vous sûr de vouloir clore les votes ?",
"<front>", $desc);
}
?>

Ensuite on retombe dans le fonctionnement classique des formulaires, il suffit de faire le traitement des données dans la fonction de submit du formulaire.

<?php
/**
* Close votes on sessions, send email to rejected contributions' authors
*/
function feature_conference_close_sessions_confirm_form_submit($form, &$form_state) {
// Set a variable to status closed
variable_set('feature_conference_status', 'closed');
drupal_set_message("Les votes sur les sessions sont maintenant clos.");
drupal_goto('<front>');
}
?>

Et nous voilà avec un formulaire de confirmation fonctionnel. Le cas d’usage est simple, si vous souhaitez faire une action plus avancée comme par exemple clore une session précise, il faut que vous passiez les données dans le formulaire de confirmation via un ou plusieurs arguments à l’url de traitement car le fait d’effectuer une redirection entraine la perte des données soumise par le formulaire principal.

Ajouter des conditions de validation à un champ CCK

admin — Wed, 04 Aug 2010 12:21:32 +0000

Lorsqu’on construit un formulaire à l’aide de CCK on bénéficie de conditions de validation de champs par défaut, afin de contrôler que la saisie de l’utilisateur est bien un nombre, du texte ou de type adresse mail… Prenons l’exemple du module phone qui permet de saisir des numéros de téléphone, celui-ci vérifie lors de la validation que ce qui à été tapé semble bien être un numéro.

Il peut vous arriver d’avoir besoin de vérifier autre chose, par exemple pour un numéro de série vous allez faire un contrôle sur la structure de l’information et le nombre de caractères.

Pour personnaliser la vérification de nos champs de formulaires nous allons ajouter, grâce à un form_alter, un appel à nos fonctions de vérifications.

function mymodule_form_alter($form_id, &$form) {
// Si vous voulez controler un champs pour un type de contenu en particulier
$allowed_node_types = array(
'mymodule1',
'mymodule2',
);

// On vérifie que l'on est bien sur un formulaire de type de contenu et qu'il appartient à la liste précédente.
if (substr($form_id,-10)=='_node_form' && in_array(substr($form_id, 0, strlen($form_id)-10), $allowed_node_types)) {
// Note : Vous pouvez ajouter autant de fonctions de vérification que vous en avez besoin
$form['#validate'][] = '_mymodule_form_validate';
}
}

Il ne nous reste plus qu’à construire notre fonction de vérification

function _mymodule_form_validate($form_values, $form)
{
// Vous pouvez alors vérifier votre champ et avertir l'utilisateur d'un éventuel probleme.
if ($form_values['monchamp'][0]['value'] == 'Quelque chose à vérifier') {
form_set_error('monchamp', 'Le message d'erreur pour l'utilisateur');
}
}

Voilà, en quelques lignes nous venons d’ajouter nos propres conditions de validation à notre champ CCK.

Poste de développeur Drupal à pourvoir

Riff News — Tue, 03 Aug 2010 22:00:00 +0000

OSInet recherche un nouveau membre pour étoffer son équipe Drupal

en lire plus

Modifier/Overrider facilement le CSS d'une page Drupal

admin — Mon, 26 Jul 2010 16:09:23 +0000

Il arrive qu'on veuille modifier rapidement l'aspect d'une page sans forcément avoir le courage d'aller chercher dans le CSS du thème ou se trouve la partie à modifier, où de créer une nouvelle feuille de style pour écraser la propriété.

Pour cela, il existe CSS Injector, qui permet d'éditer les propriétés CSS dans toutes ou certaines pages.

Une fois le module installé et activé, rien de plus simple : Configuration du site > CSS injector

Ajouter une nouvelle règle

Chaque règle permet de modifier le CSS d'une ou plusieurs pages. Je vous conseille donc de créer soit des règles selon les pages où elles vont être appliquées, par exemple "Toutes les pages", "Page d'accueil", "Noeuds", etc. soit selon l'élément qu'elles vont affecter, par exemple "Suppression des puces", "Mise en forme des commentaires", etc. Ou encore les deux !

De cette manière l'administration de ces règles sera d'autant plus facile.

Ecraser une propriété existante

Souvenez vous que CSS Injector n'est qu'un module, il sera donc appelé avant le thème et sera écrasé par celui-ci (voir mon article sur le processus de theming Drupal), pour écraser une propriété d'un thème, il vous faudra donc user de la hiérarchie CSS :

body .block-locale ul li {
list-style-type: none;
}

pour écraser :

.block-locale ul li {
list-style-type: none;
}

ou encore d'utiliser le flag !important pour spécifier au navigateur que votre propriété est la plus importante.

Le cache

L'option Preprocess CSS (cochée par défaut) permet d'utiliser l'option preprocess de drupal_add_css pour que CSS Injector s'intègre aux CSS aggrégés et respecte le cache Drupal donc si vous ne voyez rien changer sur votre page : pensez à le vider !

Condition PHP

Le formulaire d'édition des règles permet d'utiliser un code PHP pour intégrer le code CSS. On peut donc aisément changer de background général selon l'heure de la journée :

Code CSS

body {
background: url('sites/all/themes/montheme/img/bg_nuit.png');
}

Code PHP

<?php
if((int)date('H') < 8 || (int)date('H') > 21)
return TRUE;
?>

Attention aux erreurs PHP !

Whisky Echo Bravo vous invite à une rencontre Drupal

Echo Bravo — Tue, 20 Jul 2010 21:29:23 +0000

Joignez-vous à nous le 12 août prochain

Nous vous invitons à découvrir nos locaux, situés à deux pas du Canal Lachine. Venez nous voir et discuter Drupal, peu avant la Drupalcon de Copenhague!

Whisky Echo Bravo vous invite à une rencontre Drupal

Echo Bravo — Tue, 20 Jul 2010 21:29:23 +0000

Joignez-vous à nous le 12 août prochain

Nous vous invitons à découvrir nos locaux, situés à deux pas du Canal Lachine. Venez nous voir et discuter Drupal, peu avant la Drupalcon de Copenhague!

france.fr : Error 500 - Internal incompetence error ?

arNuméral — Tue, 20 Jul 2010 09:11:12 +0000

Normalement je n'aurais pas eu grand-chose à faire des mésaventures de france.fr qui s'est lamentablement cassé la binette, et en fanfare, le 14 juillet dernier, si ce dernier n'avait pas tourné sous Drupal. Et même sachant ça, cela n'aurait pas été un sujet non plus si depuis le crash, je n'avais pas entendu mille fois la tirade du "Normal, c'est du Drupal, donc ça broute", déclinée dans tous les styles (spipien, wordpression, j'en passe, et des moins mûres).

Les chiffres

Pour commencer, je n'ai aucune idée de la manière dont ce site a été construit ni comment il fonctionne. C'est d'ailleurs fou le peu d'information que l'on arrive à glaner sur un projet financé à grand frais sur nos deniers. Pour ce que j'ai pu trouver, le site a coûté 800 000 euros, il a été réalisé par le société modedemploi (merci à Damien Leloup pour l'astuce qui m'a permis de le vérifier), une société très réputée dans le monde Drupal... et l'ensemble tournerait sur 12 machines (je n'ai pas réussi à trouver confirmation formelle de ceci).

En cherchant bien, nous avons malgré tout quelques informations. Cela commence avec une suprenante déclaration d'un responsable du gouvernement (au moins j'aurais appris qu'il y a des gens responsables dans ce gouvernement...) :

(...)lors du lancement de site, le nombre de connexions a atteint la barre des 2.000. Mercredi matin, le cap des 25.000 était franchi, provoquant la paralysie du serveur(...)

Déjà j'ai un peu de mal avec les imprécisions (ou noyage de poisson), car 25000 connexions pour une 1/2 journée (extrapolons donc à 50000 pour la journée entière du mercredi) ça veut dire quoi ? Ce sont des pages servies, des visiteurs uniques ? toutes les connexions (css, images, etc) ? Si ce sont des pages, cela me semble bien peu, et si ce sont des visiteurs uniques, ce n'est pas beaucoup plus brillant.

Sur France Intox, l'extrapolation à 50000 est confirmée par le directeur du SIG :

(...)une surprenante (...)environ 50 000 visiteurs un jour férié.

Déjà j'aime beaucoup le concept de "surprenante affluence" de 50000 visiteurs (uniques j'imagine) pour un site web international, qui représente la France, ouvert un 14 juillet, en pleine période touristique. ici le tragique flirte avec un comique qui ne va pas améliorer le moral lorsque nous recevrons notre prochain appel d'impôt.

Maintenant pour moi la notion de "visiteur unique" est sûrement très intéressante pour la mesure d'audience, mais n'a aucun intérêt d'un point de vue technique. A cet indicateur je préfère le nombre de pages servies par minutes et par serveur. J'ai constaté que pour un site de contenu, à un visiteur unique correspond en gros en moyenne 4 pages servies (je subodore que ce soit bien moins important pour france.fr, chiffrage optimiste donc).

Donc on peut imaginer que le site france.fr s'est étouffé à 200 000 pages servies par 12 machines pour la journée du mercredi 14 juillet, soit 11 pages par minutes et par serveurs (ppms)... Énorme, en effet... Sauf si les 12 bécanes sont en réalité un cluster de TO7 en nano-réseau rescapés du plan "Informatique pour tous", il y a comme un problème...

Éléments de comparaison

A titre de comparaison, et avant de parler d'inneficience de Drupal, Rue89 mange 2 millions de visiteurs uniques par mois avec seulement 4 serveurs. Ce qui nous donnes du 46 pages par minute et par serveur (toujours en prenant 1 visiteur unique = 4 pages). Donc déjà cela prouve que Drupal peut aller un peu plus loin que du 11 ppms.

Maintenant si je jette un oeil aux graphiques de mediapart.fr, disons à minuit, on ne peut pas dire que le trafic soit monstrueux (et nous ne sommes pas non plus dans le cas de la semaine dernière, avec une affaire Bettencourt). A cette heure je vois que l'ensemble des 4 drupaux médiapartiens servent, 200 pages par minutes en moyenne. Chaque machine étant à peine à 25% de charge... Transposé sur une journée cela nous donne 288000 pages. Approximation ridicule (le trafic double en journée) mais déjà là, on est au-dessus de france.fr.

Pour être plus objectif encore, j'ai fait un coup de cat/get/wc sur les logs apache de l'une des machines (la flemme de faire une agrégation tous les logs :-). Résultat : 175000 pages services en 24h, soit donc 120 ppms.

Conclusion

Mes calculs reposant sur une conversion un peu foireuse entre les nombres de visiteurs communiqués et la réalité des pages servies, ils valent ce qu'ils valent, c'est à dire pas grand chose. Cependant cela prouve tout de même qu'il existe des sites Drupaux qui tournent à un bien plus important régime avec bien moins de machines. Donc l'argument de l'inefficience de Drupal me semble un peu fallacieux. Qu'un Drupal brut de coffrage tourne moins vite qu'un SPIP je n'en doute pas une seconde, mais moins vite ne signifie pas obligatoirement beaucoup plus lent.

Ensuite si l'on cherche les causes possibles, nous avons déjà l'erreur de paramétrage de Drupal (genre "Oups, on a laissé le cache en base les gars, la boulette !!") ? J'en doute, cela aurait été réglé depuis une semaine que le site est HS. Nous avons aussi comme cause possible le grand classique du drupal super lourd gavé jusqu'à la trogne de modules boulimiques enquillés à la vas-y-que-je-te-pousse ? J'en doute aussi car ce site est totalement anonyme (à ce que j'ai eu le temps d'en voir). Cela veut dire que très rapidement l'ensemble des pages se trouvent compressées dans le cache frontal et servies sans requête SQL (et ce sans même sans compter sur un reverse-proxy comme Varnish). Et si les intégrateurs avaient oublié d'installer un truc aussi basique que memcache, en une semaine, je gage que cela serait tout de même déjà fait.

Reste la solution la plus simple, l'erreur sur l'architecture technique. Ce n'est en effet pas parce que l'on enquille 12 serveurs que le site va pédaler plus vite (ce n'est pas des rameurs que l'on peut ajouter pour aller plus vite ;-). Cela peut donc être une base de données sous-dimensionnée ou en MyISSAM (problème de lock) qui étoufferait les drupaux lors de la génération initiale des pages en cache, l'oubli d'un réseau privé entre les machines du cluster, etc, etc.

Bref, désolé pour les SPIP & Wordpress (que j'apprécie au demeurant), plein de raisons possibles, mais de par le profil purement anonyme du site, ce n'est clairement pas un problème de Drupal (ou alors les auteurs de ce site sont réellement des savates, ce qui n'est pas exclu).

Exposer des critères supplémentaires à Context

admin — Tue, 20 Jul 2010 06:30:42 +0000

Est-il toujours nécessaire de présenter Context, le module de Development Seed (Grands utilisateurs du célèbre triptyque Panels, Context et Spaces utilisé dans la distribution Open Atrium) ? Oui ? Et bien je vais citer Marie-Hélène qui vous le présente sur Drupalistic

Context est une manière pratique et relativement rationnelle de configurer l’affichage des blocs en fonction de la « section » du site sur laquelle on se trouve.

Un exemple couramment cité est de définir un context blog, actif lorsque l’utilisateur visualise un billet de blog, dans lequel vont apparaître les blocs « derniers commentaires », ou « derniers billets », par exemple. Cela évite, lorsque l’on souhaite modifier l’aspect d’une section, de devoir éditer la configuration de chaque bloc et la modifier à la main, en risquant d’oublier un paramètre.

Voilà pour la présentation, admettons maintenant que vous vouliez définir votre contexte en vous basant sur un type de contenu définit comme Organic Group de type « Group post ». Pour cela vous devez implémenter le hook hook_context_conditions() qui permet d’ajouter des conditions à remplir pour déterminer le contexte.
Ce hook est assez simple, il doit retourner un ou plusieurs champs de formulaire qui représentent les conditions que vous voulez ajouter. Dans notre exemple, nous exposons les types de contenu définis en tant que « group post ».

/**
* Implements hook_context_conditions().
*/
function group_post_expose_context_conditions() {
$items = array();
$groups = array();
$types = node_get_types();
// Parcourir la liste des types de contenus pour trouver si des types de contenu
// sont des "group" (lire des "group post")
foreach ($types as $type) {
if (variable_get('og_content_type_usage_' . $type->type, 'omitted') == "group") {
$groups[$type->type] = $type->name;
}
}
// Si des types de contenu sont des group post
// Il suffit de les ajouter à l'entrée de formulaire $items
// Ce champ est utilisé dans context
if (count($groups) > 0) {
$items['group_posts'] = array(
'#title' => t('Group post family'),
'#description' => t('If the post is displayed as a child of the group (the group is in the url).'),
'#type' => 'checkboxes',
'#options' => $groups,
);
}
return $items;
}

Aperçu des données exposées

Vous pouvez donc définir de nouvelles conditions pour activer votre contexte, mais il manque une étape indispensable pour se faire, il vous faut déterminer le moment où vous donnez la valeur de votre contexte. Par exemple activer le contexte « concours » lorsque l’utilisateur visualise un group post de type « concours ».
Pour cela, il vous faut simplement appeler la fonction context_set_by_condition() au bon moment. Cette fonction prends deux paramètres, le premier est la condition à laquelle vous voulez donner une valeur et le second est la valeur de cette condition.
Voici un snippet dans le contexte de notre exemple :

/**
* Implements hook_nodeapi().
*/
function group_post_expose_nodeapi($node, $op) {
if($node->type == "concours" && $op == "view") {
// "group_posts" est le nom du champ définit dans le hook_context_conditions()
// $node->type représente la valeur à donner à cette condition (ce champ de formulaire) (ici "concours").
context_set_by_condition('group_posts', $node->type);
}
}

Et le tour est joué ! Lorsque nous afficherons un noeud de type concours, notre contexte sera actif, libre à vous de l’utiliser comme bon vous semble, vous pouvez afficher un bloc supplémentaire, cacher une région etc.

Si vous aussi vous avez des astuces à partager sur Context, n’hésitez pas à les publier dans les commentaires.

Structure du theming sous Drupal 6

admin — Mon, 19 Jul 2010 07:45:26 +0000

Je me suis remis depuis peu au theming sous Drupal pour un projet, et le moins que l'on puisse dire, c'est qu'on peut facilement s'y perdre . Entre les preprocess, template, hooks, et autres mots barbares, on ne sait plus trop qui fait quoi.

Alors bien sûr comme toujours la documentation explique très bien le processus, mais comme je n'avais pas trop le temps de relire toutes les pages concernant le theming, j'ai trouvé un PDF qui résume le tout.

Le voici en image :

Un peu plus clair maintenant, non ?

Source

Fichier attachéTaille

Drupal_theme_flow_6.pdf74.86 Ko

Installer le book Drupal sous Coda

admin — Fri, 16 Jul 2010 08:00:00 +0000

Si comme moi vous êtes sur Mac et vous codez sur Coda (que je recommande d'ailleurs), alors voici une petite astuce qui vous séduira. Vous l'avez peut-être remarqué, Coda intègre par défaut le book de PHP, il s'agit en fait d'un version hors ligne de la documentation. Tout ça c'est bien pratique mais pour nous, fidèles développeurs de Drupal, on aimerait avoir l'API de celui-ci sous la main...

Et bien voeu exaucé !

Comment faire ? Petit tutorial :

On ouvre Coda si ce n'est déjà fait > Clic sur Books dans les modes d'affichages
Clic sur "+" en bas à gauche
On remplit de cette manière

Book title: Drupal 6 API
Book URL: http://drupalcontrib.org/
Use for Mode: PHP-HTML
Search URL: http://drupalcontrib.org/api/search/6/*

et pour l'image de couverture celle-ci est très chouette

La où ça devient intéressant, c'est que l'on a un raccourci pour tomber directement dessus : + double clic. De même, on peut rechercher sur des sites externes qui documentent également les modules tiers, comme drupalcontrib.

L'astuce est également possible pour d'autre languages et Frameworks, comme jQuery :

URL: http://docs.jquery.com/Main_Page
Search URL: http://docs.jquery.com/Special:Search?ns0=1&search=*&go=

N'hésitez pas à rajouter les vôtres en commentaire !

Source

Injecter son propre code SQL dans Views

arNuméral — Thu, 15 Jul 2010 07:50:44 +0000

Je ne vais pas revenir sur mon amour immodéré pour views, ce n'est plus trop la peine. Views est ce qu'il est et il arrive parfois que le choix de l'utiliser ne se pose pas, il est là, enraciné dans un projet, indéboulonnable sous peine d'exploser les charges. Et à chaque modification un peu conséquente c'est la même histoire, un temps de dingue à trifouiller en tout sens cette interface maudite pour obtenir à grand coup de prévisualisation une requête que j'ai en tête depuis le début. Passé un moment, on se lasse d'une telle gymnastique et je me suis donc mis à chercher, sans grande conviction, un moyen d'injecter mes propres requêtes dans Views. Et la bonne nouvelle est que oui, c'est faisable !

Pour quoi faire ?

Au delà de l'allergie atavique, de nombreuses bonnes raisons peuvent amener à vouloir injecter son propre code SQL. Déjà parce que certains exercices de style deviennent rapidement infaisables avec le générateur de requêtes (imbrications de select, group by complexes, etc.). Ensuite pour gagner du temps, car nombreux sont ceux qui vont tout de même plus vite à écrire du SQL qu'à click-clicker en tout sens. En revanche si certains comptaient par là améliorer les performances de views, qu'ils ne se fassent pas trop d'illusions. La génération de requête n'est pas, et loin de là, le poste le plus dispendieux de l'établissement. La production du markup à travers la jungle de couches passe-plat (styles de vue, style de ligne, etc.) arrive clairement en tête, et les joyeuseries dans la gestion du requêtage (voir le coup du count_query un peu plus loin) ne font que rallonger la sauce.

Altération de l'objet Query

Avant d'attaquer l'injection de pur code SQL dans nos vues, nous allons nous arrêter sur une technique plus simple qui peut déjà permettre de dynamiser la requête de manière plus complexe qu'avec l'interface graphique. Le principe de base de cette approche est d'exploiter le hook hook_views_query_alter dont le but est de permettre à un module tiers de modifier l'objet requête ($query, classe Query) d'une vue donnée ($view, classe View) avant que le code SQL ne soit généré. Query est une classe de Views qui représente symboliquement la future requête SQL. Vous y trouverez une série de champs contenant tout ce que vous avez défini dans l'interface graphique (relationships, where, orderby, etc).

Le mieux est comme pour un hook_form_alter d'utiliser la commande var_dump(...) pour déterminer ce que vous désirez changer dans la structure. A titre d'exemple, nous pourrions ensuite faire ceci :

Modification dynamique de l'objet Query avant génération du code SQL

Ici nous changions donc la clef de tri en fonction du contenu d'une variable de session. Le premier paramètre $views contient l'objet "vue" avec sa propriété $view->name que nous utilisons pour vérifier que l'on modifie bien la bonne vue. Le paramètre $query contient l'objet de classe Query représentant ce que vous avez défini dans l'IHM de Views. Pour info $query est tout simplement le champ $view->query. L'intérêt de le passer en paramètre m'échappe donc un peu.

Cette technique fonctionne bien, mais reste très liée à la manière dont views formalise les requêtes. Voyons comment descendre un cran plus bas niveau.

Écrasement de la requête SQL générée par Views

La méthode la plus simple pour injecter du vrai code SQL dans Views, est lisible ici dans la langue de Shakespeare. Le principe est d'exploiter un autre hook de l'API Views, hook_views_pre_execute. Ce hook étant invoqué juste avant l'appel à db_query nous laisse l'opportunité de changer la requête SQL qui a déjà été généré par Views à partir de l'objet Query. Voyons directement un exemple d'implémentation :

function mon_module_views_pre_execute(&$view) {
if($view->name=="ma_vue") {
// Décommenter pour voir à quoi ressemble la requête générée par Views
// echo "<pre>"; var_dump($view->build_info['query']); exit();
$view->build_info['query']=="
SELECT
node.nid AS nid,
node_revisions.title AS node_revisions_title,
users.uid AS users_uid,
users.name AS users_name
FROM bla bla bla";
}
}

Modification de la requête SQL de views, avant son exécution

La propriété $view->build_info est un tableau de trois clefs : query pour la requête SQL, count_query pour la même requête "optimisée" (on y reviendra) pour le comptage des éléments, et query_args qui est un tableau d'arguments (penser ici aux paramètres d'une fonction db_query) appliqués aux deux précédentes requêtes.

Vous n'avez donc plus qu'à écraser la valeur de query comme dans l'exemple donné plus haut. La seule contrainte est que les champs exposés dans le select aient les mêmes noms que ceux de la requête qu'aurait produit Views. C'est encore plus vrai si vous reprenez un projet existant et que vous n'avez pas envie d'aller trifouiller dans les templates.

Du coup, un bon point de départ pour notre code SQL nous est fourni par le panneau de prévisulatisation de views. Attention cependant, la requête visible dans ce panneau n'est pas toujours strictement celle qui serait générée par Views (vive la cohérence de cet outil..). La méthode la plus fiable est un petit var_dump($query->build_info['query']) dans le "if" de l'implémentation donnée plus haut.

Si la requête que vous injectez ne renvoie pas le même nombre d'éléments que celle d'origine, vous devez en injecter une seconde dans $query->build_info['count_query']. C'est en effet à ce genre de détail que l'on constate avec effroi l'efficacité de Views qui effectue systématiquement deux requêtes, même lorsqu'aucune pagination ne justifie ce comptage.

Mais plus drole encore, lorsque vous construisez cette requête count_query, ne cherchez pas à placer là-dedans un select count(*) from ... car cela ne marcherait pas. En effet, pour une raison qui me dépasse, Views utilise le champ count_query de la manière la plus barbare qui soit, en l'encapsulant dans un select count(*) from (LA_REQUETE_COUNT_QUERY). Super sympa non ? ;-)

En patchant Views

La méthode précédente fonctionne très bien mais me pose un petit problème. Déjà que Views est aussi lent qu'un facteur suisse, l'obliger à générer une requête que l'on sait pertinemment devoir écraser juste après n'est pas très acceptable.

Malheureusement il n'existe pas de hook dans l'API de views pour surcharger la génération du code SQL. Il va donc nous falloir tailler dans le vif et patcher. Le meilleur endroit que j'ai trouvé est le fichier includes/view.inc. Ce dernier contient la classe View, et plus particulièrement la méthode build($display_id = NULL) qui fait très exactement ce qui nous intéresse. En effet, à la ligne 649 (de la version 6.x-2.11) se trouve le code responsable de la génération du code SQL. Nous allons donc modifier cette procédure de sorte à permettre à un module tiers de sa propre mouture :

// Let modules modify the query just prior to finalizing it.
foreach (module_implements('views_query_alter') as $module) {
$function = $module . '_views_query_alter';
$function($this, $this->query);
}

// { YB PATCH - Don't generate queries if it's already done
if (empty($this->build_info['query'])) {
// } YB PATCH

$this->build_info['query'] = $this->query->query();
$this->build_info['count_query'] = $this->query->query(TRUE);
$this->build_info['query_args'] = $this->query->get_where_args();

// { YB PATCH - Allow a module to generate its own SQL
}
// } YB PATCH

patch de la classe View

On a fait plus complexe comme patch, avouez. Le principe est d'exploiter au maximum le hook_views_query_alter que nous avons rencontré plus haut en permettant non plus de modifier l'objet Query, mais de fournir une requête SQL tout prête. Le hack consiste donc pour Views de vérifier qu'une requête n'a pas déjà été injectée, et lancer sa propre génération le cas échéant. Notez au passage que le module une fois hacké sera plus compliqué à mettre à jour sauf si vous utilisez la technique des patchs.

Pour l'implémentation de ce hook, l'approche est strictement la même que pour la technique précédente (Ici aussi vous avez la même contrainte de devoir générer les mêmes champs en nombre et en nommage que ce qu'aurait fait views) a la nuance prés qu'il est cette fois obligatoire de générer aussi le champ count_query.

function mon_module_views_query_alter(&$view, &$query) {
if($view->name=="ma_vue") {
$view->build_info['query']="
SELECT
node.nid AS nid,
node_revisions.title AS node_revisions_title,
users.uid AS users_uid,
users.name AS users_name
FROM bla bla bla";
$view->build_info['count_query']="SELECT node.nid AS nid FROM bla bla bla";
}
}

Injection du requête SQL à la place de celle de Views

Et voilà :) Simple et efficace

Conclusion

J'espère que cette technique vous sera aussi utile qu'à moi. Si vous n'avez aucune contrainte de performance, vous pouvez vous appuyer sur la méthode douce qui a le mérite de laisser Views intact. Mais dans le cas contraire, le petit hack est un prix bien faible à payer pour retrouver enfin sa liberté.

Drupal Commons, un réseau social avec Drupal ?

admin — Wed, 14 Jul 2010 16:36:04 +0000

Annoncé il y a quelques mois par Acquia, le profil d'installation Drupal Commons est actuellement en phase beta avant une sortie prévue à la fin de la semaine prochaine. Précision importante, Drupal Commons tourne sous Drupal 6.

Rappelons que le principe du profil d'installation est de fournir une distribution Drupal préconfigurée et incluant des modules additionnels pour produire dès l'installation un site plus ou moins achevé, en tout cas très avancé. Il en existe déjà quelques unes. Chacune est "spécialisée" dans un type de site précis (à l'exception de Pressflow qui est une sorte de clone de Drupal dopé pour encaisser un trafic important).

Drupal Commons est un profil d'installation orienté "réseau social".

en lire plus

Drupal, Feature, Context, Views, mais pourquoi faire simple ?

arNuméral — Sun, 11 Jul 2010 18:20:10 +0000

La semaine dernière un de mes clients m'a commandé une modification sur son site sous Drupal pour lequel il avait avec un "très léger" souci de maintenance... Ce site étant réalisé par une vraie société maîtrisant les "best-practice Drupal" (Views et tout le tremblement), j'ai pensé m'en sortir vitesse grand V... Et pourtant, six heures plus tard j'y suis encore. Tellement abasourdi que j'ai besoin de l'écrire.

Navigation simplissime

Le site en question n'a rien de sorcier. Juste une base d'article tout ce qu'il y a de plus standard, et comme seul "exotisme", un menu principal piloté par une taxonomie arborescente à deux niveaux (rubrique/sous-rubrique). Le principe de navigation est assez simple, un menu principal reflète la taxonomie (menu déroulant donc):

On clique sur la rubrique, cela donne accès une mini-page d'accueil avec trois articles en avant.
On clique sur la sous-rubrique, et là on arrive sur la liste des articles comportant le terme de taxonomie correspondant.

Pour en venir au petit pépin de mon client, le site qu'on lui a livré marche parfaitement à un détail près, impossible d'ajouter une nouvelle rubrique/sous-rubrique. Pour ajouter les termes dans le vocabulaire adéquat, pas de soucis, mais pas de menu non plus. Il a bien essayé de régler le problème, tenté d'ajouter une page à la vue correspondante, tenté de faire le menu à la main, rien à faire. C'est là qu'il m'a refilé le bébé...

La main de la confeature

Souvent quand j'évoque ma manière de travailler avec Drupal, on me rétorque "Ouhlà, tu fais du code custom, c'est pas standard, faut utiliser des modules, sinon comment-ki-font-les-suivants-pour-maintenir". J'étais donc positivement curieux de voir comment un site fait par une société "state of art of drupal" était construit. Et je n'ai pas été déçu du voyage même si je ne sais pas encore bien comment je vais faire celui de retour...

Pour commencer, je me suis pris un usage extensif du module feature. Pour être honnête, j'ai une opinion assez mitigée sur ce générateur de module. Mais utilisé comme cela, je lui confère le titre d'hallucinante usine à gaz au fonctionnement proche de l'enregistreur de macro d'une suite bureautique. En fait features me rappelle le gag du développeur fou à qui on demande de corriger une fonction sensée renvoyer la somme de ses deux arguments. La fonction semble fonctionner, mais lorsqu'on lui donne à manger 1 et 1, elle renvoie 3. Le développeur fou ne tarde pas à trouver la solution en retirant fièrement 1 au résultat final...

Fatures c'est un peu cela. Drupal est in-fichu de proprement gérer un déploiement ? Et bien qu'à cela ne tienne, nous allons créer un générateur de module dans lequel on va injecter du code PHP représentant toute la configuration spécifique pour un site donné (les types de contenu, les champs cck, les vues..). Et comme en standard feature ne connait pas grand chose, on va lui coller features_extra qui va en plus permettre d'y coller les blocs, les menus et la taxo. Et comme un site drupal c'est loin de se limiter à s'y peu, pour le reste, on se démerde à coup de strongarm et du code custom... ah ahhhh !! je ne suis donc pas si seul :-)

Au final on hérite d'une chiée de module qui n'en sont pas vraiment car ils ne s'installent/désinstallent pas normalement, mais uniquement à travers l'interface de features. Ce dernier est alors censé mettre magiquement à jour le site sur lequel les dits modules sont déployés et redéployés. Sauf que c'est un peu de la magie à la Garcimore dès qu'il s'agit de choses un peu complexes comme la suppression d'un champ cck, au hasard...

Entendons nous bien, je suis parfaitement prêt à entendre l'intérêt de feature dans son concept même d'API exportable. Mais en l'état, le fait que ce ne soit qu'un module contribution et pas une api du coeur de drupal fait que sur une installation standard, 80% des paramétrages ne sont pas couvert (en gros dés que l'on sorte de CCK et Views). Du coup l'outil est trop contraignant pour un résultat bien modeste. De plus, lorsque le module généré est, comme pour ce projet, hacké jusqu'à la trogne, on perd tout l'intérêt de la manoeuvre car toute mise à jour de la feature est vouée à l'échec. Il s'agit donc plus de l'usage du module et de son périmètre qui pose problème, que sont idée de dépard.

Ils m'en ont mis plein la view...

En conclusion, les "state-of-art-of-drupal", comme moi, font du code (celui nécessaire pour tout ce que feature ne gère pas). Mais ma réelle découverte, c'est qu'ils font surtout du code pour télécommander des modules... Moi pour faire une liste, je fais une requête SQL, un db_query, un template pour formater le résultat de ma callback, et hop, à Créteil... Eux non. Eux ils utilisent Vieeeewzzzzzz, mais pas comme le pekin lambda, eux ils font du views, dans du code. Des milliers, je dis bien des milliers de ligne de code (4500 pour être exact...) pour paramétrer la génération automatique de vues, de pages associées à ces vues, de feeds, etc, etc, etc... Tout cela innocemment collé dans un hook_default_view_views...

Alors cela "fonctionne" finalement ? En bien pour commencer, nous avons un module pour faire la synchronisation entre le vocabulaire des rubriques/sous-rubriques : taxonomy_menu. Bon, pourquoi pas.

Pour gérer la page "front" et ses 3 articles mis en avant, on ajoute le module nodequeue et l'on fabrique une queue par rubrique. Là, la question est "comment fait-on pour associer une queue et une rubrique". En effet, elle est bonne la question... Car en fait on peut pas. Alors les astucieux ont écrit dans un module custom (encore du code !!) une fonction qui permet d'associer les queues au terme de vocabulaire en passant... par un tableau PHP en dur... Là pour le coup mon pov' client, il ne risquait pas de pouvoir ajouter sa rubrique de si tôt.

Ensuite, parmi les 4500 lignes de génération de vues, s'en trouve un millier dédié à fabriquer les vues/pages/feeds associés avec chaque rubrique en mettant ainsi la vue en relation avec le nodequeue qui va bien, grâce à la fonction PHP magique.

Après encore une grosse poignée de centaines lignes pour générer cette fois les vues des sous-rubriques et on est presque arrivé... Là on se dit qu'on aurait pu en profiter pour associer un menu à chaque page de vue ! Mais non, navigation_menu qui est trop super sympa !

En comme la vie serait triste si l'on n'utilisait pas context, on a rajouté quelques centaines de lignes de code supplémentaire pour générer les contextes associés à chaque rubrique et sous-rubriques...

Résultat des courses, views, nodequeue et context dans une interface graphique à faire fondre les plombs à FireFox (imaginez, une vue, 50 sous-rubriques, 100 onglets tout en ajax ;-). Interface qu'il ne faut absolument pas utiliser puisque tout est généré. Du coup l'intérêt de Views est incertain, mon client ne peux pas les modifiers et le développeur, lui s'empêtre dedans..

Ajouter une rubrique, mode d'emploi...

A ce stade, le client il est sous terre... Car finalement le manuel du "comment ajouter une nouvelle rubrique/sous-rubrique" ressemble à cela :

Aller dans la taxonomie pour créer la rubrique et la première sous-rubrique. Taxonomy menu n'a pas fonctionné, le menu n'est pas créé, c'est normal car la page n'existe pas encore... Le lien en lui même (taxonomy/term/xxx) ne fonctionne pas non plus vu que c'est ce type de chemin qui est utilisé par les pages de views et que du coup il y a conflit sur le routeur (c'est certain, il vaut mieux une vue plutôt que thémé simplement la page de taxonomie).
Créer un nodequeue...
Aller dans le code pour le modifier et ainsi associer ce nodequeue à l'intitulé de la taxonomie (pourquoi pas directement le tid ?)
Aller dans views, sur la vue "frontpage", cliquer sur modifier puis la supprimer. Si si, car sinon, Views ne réimporte pas proprement les vues par défaut générées plus haut. Au passage, pleurez un peu car évidemment les vues ont été un peu customisées juste ce qu'il faut pour passer 1/2 heure à les régler à nouveau (opération à refaire à chaque ajout de rubrique, youpi...)
Même motif et même punition pour la vue "sous-rubrique"... Mais heureusement j'ai découvert que je pouvais revenir (aka supprimer...) à partir de la liste des vues, donc firefox est sauvé. Ne pas s'étonner qu'à chaque click sur un lien de views ça mette 10 ans à réagir, car l'implémentation du hook responsable de la génération des vues par défaut est appelé à chaque fois...
Revenir sur la taxonomie cliquer sur modifier puis directement sauver, et cette fois le menu devrait être créé..

Pour s'en sortir...

Maintenant je ne sais pas trop ce que je vais faire. Je me doute bien que mon client ne sera pas très ravi avec la procédure que je viens d'énoncer. La première étape va donc consister à dégager feature/strongarm pour y voir plus clair. Puis j'imagine que je vais mettre en œuvre un truc un peu plus simple.

Un type de contenu "Rubrique" avec un titre, un corps et une liste de trois nœuds (nodereference). Le principe sera pour le client de créer un nouveau contenu de type "Rubrique" lorsqu'il en aura une à rajouter. J'associe automatiquement ce contenu au menu de premier niveau et avec un hook_nodeapi je fabrique synchronise le premier niveau de taxo rubrique. En gros 10 lignes de code. Du coup la rubrique étant un nœud associé à mon premier niveau de menu, je gère la "frontpage" par un simple node template. Emballé.
Pour les sous-rubriques, je laisse le client ajouter ses termes de taxo et je laisse navigation_menu les associer proprement. Du coup la liste des articles est simplement un template sur la liste standard de drupal des articles possedant un terme donné.

Donc en somme, si l'idée fonctionne, une usine à gaz avec 4500 lignes de code Views d'un côté, et un petit module custom disons de 100 lignes, pas de vues, et une pure exploitation des fonctionnalités de base de drupal. Sans aucun doute moins sexy ;-)

Conclusion

Il ne faut pas croire que je sois de mauvais esprit ici. j'ai même un certain respect pour la personne qui a servi de référent technique sur ce projet. Mais cette aventure a été instructive à plus d'un titre. Tout d'abord cela me décomplexe lorsqu'on me dit "Bouh, tu fais du code custom, c'est moins facile à maintenir que des modules". C'est sans aucun doute vrai lorsque le besoin est assez simple pour que les modules utilisés se suffisent à eux-même. Mais pousser la logique modulaire au point de télécommander des modules avec des milliers de lignes de code, c'est aberrant. Aberrant car je suis persuadé que mon équivalent "code simple" est cent fois plus lisible (en tout cas il est 100 fois plus documenté...). Ensuite ces modules ont été pensés pour être utilisés à travers des interfaces graphiques. C'est d'ailleurs souvent dommage car j'aurais préféré, même pour views, que l'API précède l'interface pour que tout le monde soit content. Toujours est il que du coup leur paramétrage ressemble plus à un remplissage de formulaire qu'à l'utilisation d'une API propre. Enfin, purée c'est d'une lenteur tout cela. A chaque click on a l'impression de manipuler un 38 tonnes avec des baquettes de tambour... et chaque "frontpage" de rubrique génère, pour un utilisateur authentifié, pas moins de 786 requêtes SQL !!!!!!!!!!

En conclusion, ce que j'en retire c'est que context est un module qui mérite que l'on s'y penche mais je lui reproche sa dépendance à ctools absolument inutile et proprement rédhibitoire. Feature est une plaisanterie. Drupal a un problème de déploiement indéniable et même grave à l'heure d'un usage professionnel de l'outil. Feature n'est donc qu'un emplâtre sur une jambe de bois. C'est lourd, peu stable, et surtout ne couvre pas toutes les fonctionnalités obligeant à recourir à du code custom. Autant utiliser Backup & Migrate. Views est un très bon outil pour le cadre d'usage "wordpress" de drupal (non péjoratif, car j'aime beaucoup wordpress), permettant à un utilisateur peu ou moyennement expérimenté de construire son site rapidement. Dans le cadre d'un usage professionnel par des développeurs professionnels, l'utilisation de cet outil comme API ne m'a clairement pas convaincu. C'est bordélique au possible et je crains le pire lors des changements de version (en gros views3 implique tout à la poubelle, comme ce fût le cas pour Views1).

Utiliser plusieurs bases de données pour un site Drupal

admin — Wed, 30 Jun 2010 08:03:19 +0000

On m’a posé une question intéressante il y a quelques jours, à savoir comment faire pour accéder à une autre base de données que celle sur laquelle est installé Drupal. N’ayant jamais rencontré cette problématique je me suis penché sur cette question.

Le principe est simple, il suffit de renseigner les connexions vers les différentes bases de données et de switcher entre elles lorsque vous en avez besoin.

Par défaut Drupal sait quelle base utiliser grâce aux informations contenues dans le fichier default/settings.php.

Vous devriez avoir quelque chose qui ressemble à ça :

$db_url = 'mysql://admin:pass@localhost/drupal';

Afin de lui permettre d’utiliser d’autres bases de données nous allons modifier et ajouter dans ce fichier les informations de connexions nécessaires.

// Notre connexion par défaut
$db_url['default'] = 'mysql://admin:pass@localhost/drupal';
// Nos nouvelles connexions
$db_url['second'] = 'mysql://root:pwd@localhost/anotherdb';
$db_url['db3'] = 'mysql://user:pwd@localhost/yetanotherdb';

Pour utiliser une autre base de données il suffit simplement de l’activer avec la fonction db_set_active en passant le nom de votre connexion.

db_set_active('second');

db_query('SELECT * FROM table_in_anotherdb');

//Retour sur la table défaut une fois terminée.
db_set_active('default');

N’oubliez pas une fois terminé de revenir sur la base par défaut

Edit : Suite à la remarque de FGM il n’est pas possible d’inclure dans le fichier settings.php des connexions vers différents types de base de données. C’est à dire que vous ne pouvez pas avoir une connexion qui utilise le driver Mysql et le driver Pgsql.

Pour comprendre il faut regarder la fonction db_set_active() dans le fichier includes/databases.inc. C’est lors de l’appel à cette fonction qu’est chargé le driver souhaité. Imaginons que je charge en premier le driver mysql (includes/database.mysql.inc) et ensuite le driver pgsql (includes/database.pgsql.inc). Nous nous retrouvons à ce moment là avec deux fichiers chargés en mémoire contenant les mêmes noms de fonctions. Or il est impossible de redéclarer une fonction sans que cela ne génère une erreur php.

Comme quoi bloguer permet d’apprendre. Encore merci à Frédéric !

Comment créer un profil d’installation

admin — Fri, 11 Jun 2010 09:00:31 +0000

Plus Drupal mûrit plus on cherche à industrialiser la production de sites. Une des solutions que l’on propose maintenant courament face à cette demande est l’utilisation de profils d’installation.
Oui, mais comment fait-on pour les créer ?

C’est très simple, commençons par reprendre l’arborescence de Drupal. On passe tellement de temps à travailler dans /sites/all/modules que l’on en oublie parfois qu’il existe d’autres répertoires où l’on peut travailler (mais jamais dans /modules ! Pensez aux chatons).

A la racine du dossier de Drupal il existe un répertoire /profiles qui contient à minima un dossier default. C’est le profil qui est utilisé à chaque fois que vous faites une installation de base de Drupal 6. Si vous avez la curiosité de regarder le contenu de ce dossier vous allez vous rendre compte qu’il n’est pas très volumineux car il ne contient que le fichier default.profile.

Organisation d’un profil d’installation

Le profil d’installation est donc composé comme suit :

/profiles/monprofil/monprofil.profile
/profiles/monprofil/modules
/profiles/monprofil/themes
/profiles/monprofil/translations

Seul monprofil.profile est obligatoire, les dossiers supplémentaires modules, themes et translations sont respectivement présents pour permettre l’utilisation de modules supplémentaires, de thèmes additionnels ou de langue complémentaires.
L’intérêt du profil d’installation est qu’il est distribuable, c’est pour cette raison que si vous utilisez des modules autres que ceux du core vous devez les placer au sein d’un répertoire modules. (Si les modules sont présents dans /sites/*/modules le code fonctionnera mais en terme le logique il est recommandé de placer ces modules dans /profiles/monprofil/modules).
Il en va de même pour les thèmes.

Et d’un point de vue code ?

Dans la plus petite version possible d’un profil d’installation (identique à default.profile) il faut à minima déclarer ces fonctions :

1) example_profile_modules() // retourne un tableau des modules à installer
2) example_profile_details() // retourne un tableau avec les détails du profil avec les deux clés name et description)

Optionnelles

3) example_profile_task_list() // Etapes intermédiaires du profil
4) example_profile_tasks(&$task, $url) // Execute les dernières taches du profil d’installation

example_profile_modules()

Cette fonction est généralement utilisée pour activer les modules de core dont vous allez avoir besoin. Pour activer les modules contribs, on a l’habitude de créer une étape intermédiaire compte tenu du fait qu’ils dépendent très souvent des modules de core et qu’ils sont nombreux (on utilisera l’API de batch afin de ne pas faire tomber le serveur).

function MONPROFIL_profile_modules() {
return array('color', 'comment', 'help', 'menu', 'taxonomy', 'dblog');
}

example_profile_details()

Difficile de sélectioner votre profil d’installation si cette fonction n’est pas présente car elle indique son petit nom et une description.

function MONPROFIL_profile_details() {
return array(
'name' => st('Custom installation profile'),
'description' => st('This is my first installation profile')
);
}

Note : Au sein d’un profil d’installation il faut utiliser la fonction st() au lieu de t() pour internationaliser vos chaines de caractères. Les fichiers .po doivent se trouver au sein du dossier /profiles/monprofil/translations.

example_profile_task_list()

Si vous créez des étapes intermédiaires dans votre profil il est intéressant d’indiquer à votre utilisateur sa progression. Ce sont les états que l’on retrouve à gauche au cours de l’installation.

function openatrium_profile_task_list() {
return array(
'intranet-modules-batch' => st('Install intranet modules'),
'intranet-configure-batch' => st('Configure intranet'),
);
}

example_profile_tasks(&$task, $url)

C’est la fonction la plus utile du profil d’installation car c’est dans cette dernière que l’on va faire la configuration des modules, la création de types de contenus, la création de nodes, d’utilisateurs bref c’est là que l’on fait réellement ce qui nous intéresse.
Voici une copie de l’implémentation de cette fonction dans le profil d’installation d’Open Atrium, je reviendrai ci-dessous en détails sur les parties importantes.

Premier point important, le déroulé des étapes :

profile
intranet-modules
intranet-modules-batch
intranet-configure
intranet-configure-batch
profile-finished

La première étape d’un profil d’installation à partir de laquelle l’installeur vous donne la main est toujours « profile » et vous devez avoir comme dernière étape « profile-finished » pour rendre la main à l’installeur. Vous ne pouvez donc pas intervenir sur ce qui se passe avant et après !

Votre profil d’installation va donc passer autant de fois que nécessaire dans la fonction hook_profile_tasks(), les seuls conditions nécessaires pour que la répétition cesse sont :

Vous donnez la valeur « profile-finished » à la variable $task
Vous ne changez pas la valeur de la variable $task

Pour passer d’une étape à une autre vous devez changer la valeur de $task. Si vous affichez un formulaire ou exécutez une action en batch vous allez devoir utiliser variable_set(‘install_task’, ‘valeur-tache’); pour stocker l’étape dans laquelle vous êtes.

On voit également dans le profil d’installation d’Open Atrium comment gérer une opération en batch, c’est une action en deux étapes, la première consiste à créer le batch, définir la(es) opération(s), la fonction à exécuter à la fin du batch et toutes les variables propres aux batchs (cf Batch API pour plus d’informations) et la seconde lance le traitement du batch _batch_page(); . Difficile à inventer si on ne l’a jamais vu .

Je vais terminer avec un snippet pour afficher un formulaire comme étape du profil d’installation, c’est là aussi une opération particulière car il faut faire deux choses, il faut d’abord bloquer la redirection du formulaire avec $form['#redirect'] = FALSE; et ensuite préciser vers quelle url soumettre le formulaire grâce à $form['#action'] = $url; (en pensant à passer $url comme paramètre supplémentaire à votre formulaire) pour que votre formulaire permette la poursuite de l’exécution du profil.

// Extract of the hook_profile_tasks
// Define extra actions if the development environment is enabled
if ($task == 'development-environment') {
$output = drupal_get_form('custom_profile_dev_form', $url);

if (!variable_get('developement_environment_checked', false)) {
drupal_set_title(st('Select the environment you want to setup'));
return $output;
}
else {
$setup_dev_env = variable_get('setup_dev_env', FALSE);
variable_del('developement_environment_checked');
variable_del('setup_dev_env');

// Setup the environment dev if checked
if ($setup_dev_env) {
$task = 'setup-dev-env';
}
else {
$task = 'install-extra-modules';
}
}
}

// --

// Custom form
function custom_profile_dev_form(&$form_state, $url) {
$form = array();
$form['#redirect'] = false;
$form['#action'] = $url;
$form['development_environment'] = array(
'#title' => st('Enable development environment'),
'#type' => 'radios',
'#options' => array('No', 'Yes'),
'#default_value' => 1,
'#required' => TRUE,
'#description' => st('This will install modules like Devel and create dummy content.'),
);
$form['submit'] = array(
'#type' => 'submit',
'#value' => st('Confirm'),
);
return $form;
}

Voilà qui termine un assez long article sur les profils d’installation, n’hésitez pas à partager vos astuces et à poser vos questions dans les commentaires.

Jouez à cache-cache avec Drupal

admin — Tue, 08 Jun 2010 07:00:20 +0000

Sommaire
1. Premiers pas avec le caching
2. L’API de cache de Drupal
3. Mise en place du cache
4. Nettoyage du cache
5. Fraîcheur de l’information
6. Créer une table de cache dédiée

Qui n’a jamais eu besoin d’améliorer les performances de son site pour booster Drupal?

Effectivement, lorsque l’on travaille sur des gros sites il faut se poser des questions sur les performances de Drupal, parce qu’on le sait tous, Drupal est gourmand. L’affichage d’une simple page peut parfois engendrer l’exécution de 50 voir 150 requêtes.

©copyright

Imaginez vous cette même page appelée par plusieurs internautes en même temps. On obtient alors des centaines de requêtes et informations recalculées inutilement qui vont solliciter les serveurs et vont ainsi consommer du CPU et de la RAM alors qu’elles auraient pu tout aussi bien être sauvegardées.

Pour sauvegarder ces informations il faut donc mettre en place un système de caching qui va mémoriser pour un temps donné des informations afin de ne pas les recalculer.

Le caching de page va avoir plusieurs impacts sur notre site :

Baisse du temps de chargement de la page
Diminution de l’utilisation des serveurs qui pourront faire autre chose à la place.
Améliorer votre référencement auprès de Google, puisqu’il prend maintenant en compte la vitesse de chargement des pages.

La solution de caching n’est pas l’arme ultime pour améliorer les performances de votre site mais elle permet d’alléger la charge de travail du serveur et de le rendre plus disponible.

Premiers pas avec le caching

La solution la plus simple à mettre en place est d’activer le cache de page depuis l’administration de Drupal [admin/settings/performance]. C’est un cache simple mais efficace qui mémorise le résultat de la page. Malheureusement cette solution n’est disponible que pour la naviguation des utilisateurs anonymes, mais n’ayez crainte il existe belle et bien une solution pour les visiteurs authentifiés

Cette solution consiste à effectuer soi-même la mise en cache et l’affichage en utilisant l’Api de Drupal, mais cela implique néanmoins de savoir ce que vous voulez sauvegarder et afficher.

L’API de cache de Drupal

Celle-ci est composée de trois fonctions :

cache_set pour sauvegarder

cache_set($cid, $data, $table = ‘cache’, $expire = CACHE_PERMANENT, $headers = NULL)
- $cid : C’est la clé permettant l’identification de ce que vous voulez sauvegarder. Celle-ci doit être unique, utilisez quelque chose qui ne pourra pas être créé par un autre module. Le plus simple est de préfixer votre clé avec le nom de votre module.
- $data : Ce sont les données à sauvegarder, ne vous inquiétez pas du typage et de la structure de vos données celles-ci sont sérialisées lors de l’enregistrement.
- $table : Par défaut vous enregistrerez dans la table nommé ‘cache’ mais vous pouvez tout aussi bien spécifier une autre table.
- $expire : Si vous souhaitez rafraîchir les informations stockées en cache vous allez devoir définir une période de validité pour celles-ci.
- $headers : Cette variable est utile si vous souhaitez passer des informations d’en-tête HTTP aux pages mises en cache.

cache_get pour récupérer les informations

cache_get($cid, $table = ‘cache’)

cache_clear_all pour nettoyer ce qui a été enregistré

cache_clear_all($cid = NULL, $table = NULL, $wildcard = FALSE)
- $wildcard : Par défaut à False, cette variable peut, si elle est passée à True, sélectionner toutes les occurrences retrouvées commençant par le $cid renseigné.

Mise en place du cache

function my_module_function() {
// Récupération du cache s'il existe
$cache = cache_get('my_module_data');
if (is_object($cache) && !empty($cache->data)) {
$my_data = $cache->data;
}
else {

// fonction de génération de votre contenu

// Sauvegarde des informations calculées.
cache_set('my_module_data', $my_data);
}
return $my_data;
}

Analysons le code ci-dessus simplifié pour l’exemple. Dans un premier temps la fonction cache_get() à été utilisée pour savoir si oui ou non, nous avions des données enregistrées a retourner directement à l’utilisateur. Dans le cas contraire les informations ont été générées puis mise dans la table de cache via la fonction cache_set().

Dans cette table vous pouvez stocker tout ce que vous voulez, un rendu html ou encore le calcul d’une lourde opération mais dites vous bien que les informations dans cette table ne sont qu’éphémères et peuvent à tout moment disparaître.

Nettoyage du cache

Il peut vous arriver de vouloir vider vos données sauvegardées tout simplement pour que celles-ci soient régénérées ou pour faire un export complet de votre base (ne prenez pas les données contenues dans les tables de cache, elle ne font que grossir la taille de votre export sans réel besoin).

Le nettoyage des caches se fait avec la fonction cache_clear_all() qui permet de supprimer ce qui nous concerne sans toucher au reste.
Par défaut celle-ci n’a besoin que d’une chaîne de texte ($cid) afin de trouver et effacer l’occurence dans la table de cache, mais si $wildcard est passé à True alors toutes les valeurs commençant par votre $cid seront effacées.

cache_clear_all('my_module_data', 'cache', TRUE);

Cet exemple supprime toutes les entrées de cache commencant par ‘my_module’.

Fraîcheur de l’information

Par défaut les informations que vous avez sauvegardées en cache sont gardées indéfiniment ou du moins jusqu’à ce que vous les ayez effacées avec la fonction cache_clear_all. La problématique sur la fraîcheur de données se pose alors car cette méthode n’est pas viable si vous souhaitez cacher des informations qui doivent être recalculées souvent.

Pour palier au cache permanent nous allons définir lors de l’enregistrement une date d’expiration aux données. Celle-ci sera comparée à la date en cours lors de la récupération afin de voir si les données sont encore valables.

cache_set('my_module_data', $my_data, 'cache', time() + 300);

La date d’expiration doit être au format unix timestamp et la façon la plus simple pour définir cette valeur est d’ajouter une période en seconde au timestamp en cours. Cet exemple défini une validité de 5 minutes (60sec x 5).

Créer une table de cache dédiée

Nous venons de voir comment sauvegarder des informations dans la table de cache par défaut de Drupal, mais il est aussi possible de créer votre propre table de cache surtout si vous pensez avoir beaucoup d’informations à stocker. Ceci évitera d’avoir une grosse et unique table de cache.

Voici un petit exemple pour mieux comprendre l’interêt d’une table de cache dédiée. Imaginons que j’ai 200.000 urls raccourcies à mettre en cache. Par défaut cela aurait crée 200.000 nouveaux enregistrements dans la table de cache standard, ce qui aurait eu pour conséquence d’augmenter le temps d’exécution des requêtes sur la base de données parce que Mysql aurait été obligé de parcourir tous les enregistrements à chaque fois. En créant notre table dédiée on garde les performances de la table cache et on ne parcourt nos 200.000 valeurs qu’en cas de besoin.

Le plus simple à faire pour créer un autre table de cache est de faire une copie de la table standard ‘cache’ comme cela on est sûr d’avoir le même schéma de base de données. Pour cela la récupération du schema original et non modifié de la table ‘cache’ sera fait avec la fonction drupal_get_schema_unprocessed($module, $table = NULL).

/**
* Implementation of hook_schema().
*/
function my_module_schema(){
$schema = array();
$schema['cache_my_module'] = drupal_get_schema_unprocessed('system', 'cache');
return $schema;
}

Par convention nommez votre table ‘cache_’ puis le nom de votre module ce qui dans l’exemple ci dessus donne ‘cache_my_module’.

Le schema de base de données est prêt, il faut maintenant écrire les fonctions permettant la création et la suppression de celui-ci (hook_install et hook_uninstall) dans le fichier .install du module.

A ce stade la mise en place de la table de cache dédiée est terminée, il ne reste plus qu’à activer le module et à vérifier que celle-ci à bien été ajoutée à la base de donnée.

Pensez aussi à modifier les fonctions drupal_cache_get(), drupal_cache_set() et cache_clear_all() pour qu’elles pointent vers la bonne table.

cache_set('my_module_data', $my_data, 'cache_my_module');
cache_get('my_module_data', 'cache_my_module');

Un dernière chose sur le stockage des informations en cache, il est tout à fait possible de les sauvegarder vers un serveur spécialisé type memcached, APC, ou autre.

Vous voilà maintenant prêt à améliorer votre code. Si vous voulez en lire plus voici la présentation officielle de l’api cache de Drupal ou sinon le guide Lullabot sur l’utilisation de l’api.