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 !

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
  if (($cache = cache_get('my_module_data')) && !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.

Un formateur CCK permet de transformer l’affichage d’un champ en ce que l’on veut, ce n’est ni plus, ni moins qu’une fonction de thème.

Le choix de l’utilisation d’un formateur se fait par l’intermédiaire de l’administration des types de contenus via la rubrique ‘Afficher les champs’. Pour chaque champ vous avez un menu déroulant avec les différents formateurs disponibles.

Prenons l’exemple d’un champ image. Grâce aux différents formateurs disponibles vous avez le choix d’afficher à l’internaute un lien url du fichier, le chemin de l’image ou encore l’image elle même.

La réalisation d’un formateur est vraiment simple. Nous allons donc voir comment en créer un afin de transformer l’affichage d’un champ texte dans lequel on saisit des numéros de téléphone en quelque chose de plus lisible. Cet exemple n’a pas grand interêt mais il va nous permettre de mettre en œuvre facilement la création d’un formateur.

1) Déclaration du formateur CCK

Tout commence par la déclaration de notre formateur à Drupal par le biais de la fonction hook_field_formatter_info()

/**
* Implementation of hook_field_formatter_info().
*/
function monmodule_field_formatter_info() {
  $formatters = array(
    'customphonenumber' => array(
      'label' => t('Modif num tél'),
      'field types' => array('text'),
      'description' => t("Transformation de l'affichage d'un numéro de téléphone"),
    ),
  );

  return $formatters;
}

Grâce à cette fonction nous venons de déclarer notre nouveau formateur ‘customphonenumber’ ainsi que ses paramètres.
- label : c’est le nom qui sera affiché dans la liste des formateurs disponibles
- field types : c’est la liste des champs cck sur lesquels vous pourrez appliquer le formateur.
- description : la description complète de votre champ.

2) Implémentation de la fonction de thème

Nous allons maintenant implémenter le hook_theme() afin d’appliquer un thème à notre formateur.

/**
* Implementation of hook_theme().
*/
function monmodule_theme() {
  $theme = array(
    'monmodule_formatter_customphonenumber' => array(
      'arguments' => array('element' => NULL),
    ),
  );

  return $theme;
}

Il ne nous reste plus qu’à construire notre thème afin de modifier l’apparence du champ.

3) Création de notre thème

Notre thème va nous permettre d’effectuer les transformations que l’on veut sur notre champ. Toutes les informations du champs se trouvent dans la variable $element.

/**
* Theming functions.
*/
function theme_monmodule_formatter_customphonenumber($element) {
  $output = '';
  $phone_number = $element['#item']['value'];
  $output = wordwrap(filter_xss($phone_number), 2, '.', 1);

  return $output;
}

Maintenant pour appliquer votre formateur il ne vous reste plus qu’à vous rendre sur la page ‘Afficher les champs’ de votre type de contenu afin de le sélectionner. N’oubliez pas que pour que votre champ apparaisse dans la liste, vous devez régénérer les thèmes disponibles en flushant vos caches, afin que vos modifications soient prises en compte.

#1 – Les Statistiques d’usage.

Sur chaque page de modules il y a un lien en bas de page appelé ‘View usage statistics‘ qui vous renvoie vers une page dédiée aux statistiques d’utilisation du module. La courbe présentée vous donne une estimation de l’utilisation du module (cette courbe ne colle pas forcément avec la réalité car les statistiques sont calculées grâce aux sites ayant le module update activé). Vous pouvez néanmoins tirer des conclusions de cette courbe, si celle-ci ne fait que progresser c’est bon signe, à l’inverse si elle chute il faut se poser des questions. Pourquoi a t-elle chuté? Y’a t’il un autre module qui fait mieux que celui-ci? A ce moment vous êtes bon pour continuer votre recherche.

#2 – La date de la dernière release.

La date de la dernière version disponible d’un module est un bon indicateur. Si celle-ci est proche de la réalité cela veut dire que le mainteneur du module est toujours actif et qu’il corrige ou ajoute encore des fonctionnalités à son module. C’est important de savoir que si vous avez besoin vous pourrez trouver un peu d’aide au près de celui qui a développé le module. Attention cependant, ce n’est pas non plus parce qu’un module à une date de release assez vieille que celui-ci n’est pas ou plus maintenu, il faut prendre en compte le point #3 dans ce cas.

#3 – Le Nombre d’issue ouverte et le temps qu’il a fallut pour les résoudre

Pour chaque module il est possible d’ouvrir des issues. Une issue, c’est une question ou une demande formulée au mainteneur, qui peut prendre plusieurs formes. Cela peut être un bug, une demande d’aide ou d’ajout de fonctionnalité, ou encore la proposition d’un patch…
Sur chaque page de module il y a un encadré dédié aux issues en haut à gauche, sur cet espace vous pouvez visualiser le nombre d’issue et de bug non résolus. Forcément, plus les chiffres sont élevés plus vous avez de questions à vous poser sur le module.

Ce qui est donc important de regarder c’est le nombre d’issues encore ouvertes et le temps qu’a mis le mainteneur pour répondre et corriger celles qui sont fermées afin de connaître son temps de réaction.

#4 – Le ou les responsables du modules

Si vous débutez avec Drupal vous allez avoir un peu de mal à appliquer ce conseil, mais à force de jouer avec Drupal vous allez vous apercevoir que certains noms reviennent parmi les contributeurs. Donc lorsque vous tombez sur un module développé par quelqu’un de « réputé » vous pouvez vous attendre à un travail de qualité.

#5 – La qualité du code

Ce conseil s’applique si vous savez développer un module puisqu’il vous faut regarder le code source de celui-ci. Regarder la façon dont est codé un module est un bon indicateur, vous pouvez ainsi voir si les normes de codages de Drupal sont respectées (utilisation de l’api, respect des standards, indentation et documentation du code…) et puis cela vous permettra de  mieux comprendre comment fonctionne le module si vous l’utilisez.

Voilà maintenant que vous savez repérer un module qui a du potentiel vous pouvez vous plonger dans la liste de modules de Drupal.

Vous trouverez donc sur cette page une petite sélection de modules classés par thème, dont certains très connus et d’autres moins.

Imaginez un type de contenu ‘Articles’ composé des champs traditionnels title et body et de mon champ extra ainsi qu’un deuxième type de contenu ‘Actualités’. Nous allons donc voir comment récupérer ce champ du premier contenu pour l’intégrer au deuxième.

Tout d’abord il nous faut récupérer le champ. Pour cela nous allons utiliser la fonction content_fields() de CCK en lui passant le nom du champ à récupérer et le contenu sur lequel le trouver.

  $cck_field_copy = content_fields('field_articles_extra', 'articles');

Note : le nom du champ cck se trouve dans l’onglet ‘Gérer les champs’ sur l’interface d’administration de votre type de contenu. C’est le nom machine que vous avez saisi lors de la création.

Voici ce que contient mon champ field_articles_extra :

array (
  'field_name' => 'field_articles_extra',
  'type_name' => 'articles',
  'display_settings' =>
  array (
    'label' =>
    array (
      'format' => 'above',
      'exclude' => 0,
    ),
    'teaser' =>
    array (
      'format' => 'default',
      'exclude' => 0,
    ),
    'full' =>
    array (
      'format' => 'default',
      'exclude' => 0,
    ),
    4 =>
    array (
      'format' => 'default',
      'exclude' => 0,
    ),
    2 =>
    array (
      'format' => 'default',
      'exclude' => 0,
    ),
    3 =>
    array (
      'format' => 'default',
      'exclude' => 0,
    ),
  ),
  'widget_active' => '1',
  'type' => 'text',
  'required' => '0',
  'multiple' => '0',
  'db_storage' => '1',
  'module' => 'text',
  'active' => '1',
  'locked' => '0',
  'columns' =>
  array (
    'value' =>
    array (
      'type' => 'text',
      'size' => 'big',
      'not null' => false,
      'sortable' => true,
      'views' => true,
    ),
  ),
  'text_processing' => '0',
  'max_length' => '',
  'allowed_values' => '',
  'allowed_values_php' => '',
  'widget' =>
  array (
    'rows' => 5,
    'size' => '60',
    'default_value' =>
    array (
      0 =>
      array (
        'value' => '',
        '_error_element' => 'default_value_widget][field_articles_extra][0][value',
      ),
    ),
    'default_value_php' => NULL,
    'label' => 'Extra',
    'weight' => '31',
    'description' => '',
    'type' => 'text_textfield',
    'module' => 'text',
  ),
)

Maintenant que nous avons notre champ, nous allons l'adapter pour notre nouveau type de contenu en changent le nom du champ et le nom du type de contenu auquel il appartient :

// Modification de la variable pour le contenu weblinks
  $cck_field_copy['field_name'] = 'field_actualites_extra';
  $cck_field_copy['type_name'] = 'actualites';

Notre champ est prêt, il suffit maintenant d’utiliser les fonctions du module CCK pour insérer ce champ à notre contenu Actualités.

 // Chargement des dépendances CCK pour ajouter le champ.
  module_load_include('inc', 'content', 'includes/content.crud');
  // Ajout du champ slug au contenu weblinks.
  content_field_instance_create($slug_cck_field);

L’ajout de ce nouveau champ ne doit être fait qu’une seule fois et avant de commencer à créer des contenus, pour cela le meilleur endroit est le fichier .install dans le hook_install()

/**
 * Implements hook_install().
 *
 * Ajout du champ CCK slug au contenu weblinks.
 */
function MyModule_install() {
  // Copie du champ CCK extra sur le contenu articles.
  $cck_field_copy = content_fields('field_articles_extra', 'articles');  

  // Modification de la variable pour le contenu Actualités
  $cck_field_copy['field_name'] = 'field_actualites_extra';
  $cck_field_copy['type_name'] = 'actualites';

  // Chargement des dépendances CCK pour ajouter le champ.
  module_load_include('inc', 'content', 'includes/content.crud');

  // Ajout du champ extra au contenu Actualités.
  content_field_instance_create($cck_field_copy);
}

Nous venons d’installer notre champ, mais il faut aussi penser à créer la procédure de désinstallation.

/**
 * Implements hook_uninstall().
 *
 * Ajout du champ CCK slug au contenu weblinks.
 */
function MyModule_uninstall() {
  // Chargement des dépendances CCK pour supprimer le champ.
  module_load_include('inc', 'content', 'includes/content.crud');

  // Suppression du champ extra du contenu Actualités.
  content_field_instance_delete('$cck_field_copy', 'actualites');

}

Pour tester il ne vous reste plus qu’à installer votre module. Si celui-ci est déjà installé désactivez le et désinstallez le avant. Votre champ est maintenant sur votre contenu

Merci à Opi et Inade pour les différents liens qu’ils m’ont donnés.

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.

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.

function facebook_status_activity($owner, $poster, $status) {
  //If we're using Activity 2, this function doesn't need to be run.
  if (!module_exists('activity') || function_exists('activity_help')) {
    return FALSE;
  }
  //Privacy setting check.
  if (activity_user_privacy_optout($poster)) {
    return FALSE;
  }
  $data = array(
    'owner' => theme('username', $owner),
    'poster' => theme('username', $poster),
    'status-unformatted' => check_plain($status->status),
    'status-themed' => theme('facebook_status_item', $status),
    'status_time' => $status->status_time,
  );
  $target_users_roles = array(
    ACTIVITY_ALL => 'all',
    $owner->uid => 'owner',
  );
  //If $owner->uid == $poster->uid, this will just overwrite the owner role.
  $target_users_roles[$poster->uid] = 'poster';
  activity_insert($poster->uid, 'facebook_status', 'facebook_status', 'update', $data, $target_users_roles);
}

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.

Edit :

Dans le cas ou vous auriez à appliquer votre patch à l’ensemble d’un dossier vous pouvez ajouter l’option p0 à la commande patch comme le soumet Julien Dubois

$ patch -p0 < facebook_status.module.patch

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

Dans un premier temps nous allons déclarer le hook_mail qui va être utilisé pour construire l’email avec la configuration que nous avons choisie et les paramètres que nous allons passer via la fonction drupal_mail. Vous pouvez spécifier plusieurs options :

$key : Identifiant unique pour votre email.
$message : Tableau de valeurs contenant les informations relatives à l’email.
* ‘id’ : Identifiant pour distinguer l’email envoyé.
* ‘to’ : L’adresse du destinataire
* ’subject’ : Le sujet de votre email
* ‘body’ : Le contenu de votre email.
* ‘from’ : L’adresse de l’émetteur
* ‘headers : Les informations d’en-tête de votre email.
$params : Tableau de paramètres dans lequel vous pouvez récupérer les informations que vous allez passer dans la fonction drupal_mail.

function MyModule_mail($key, &$message, $params) {
  // note: l'utilisation d'une clé va nous permettre de distinguer plusieurs templates d'emails pouvant être envoyés par un même module.
  switch ($key) {
    case 'envoi_email':
      // note: Ici nous récupérons les informations passées dans le tableau $params
      $message['subject'] = $params['subject'];
      $message['body'] = $params['body'];
      break;
  }
}

La fonction drupal_mail() va nous permettre de définir un ou plusieurs templates d’emails dans lesquels nous allons pouvoir spécifier le contenu, le sujet et passer des paramètres pouvant être utilisés par la fonction hook_mail que nous venons de déclarer.

$module : Nom de votre module.
$key : La clé qui va vous permettre d’identifier votre email.
$to : L’adresse du destinataire.
$language : La langue dans laquelle sera traduit votre email.
$params : Le tableau optionnel de valeurs à passer à la fonction hook_mail.
$from : L’adresse de l’émetteur
$send : Configure l’envoi immédiat ou non de l’email

Vous pouvez appeler cette fonction à la suite d’une action d’un utilisateur sur votre site ou encore lors de la soumission d’un formulaire.

$to = 'you@example.com';
$from = 'me@example.com';

$params = array(
  'body' => t("Vous venez de recevoir cet email depuis mon site drupal"),
  'subject' =>t("test d'envoi d'email"),
);

if (drupal_mail('MyModule', 'envoi_email', $to, language_default(), $params, $from, TRUE)) {
  drupal_set_message("Votre email à été envoyé à " . $valid_email);
}
else {
  drupal_set_message("Une erreur s'est produite lors de l'envoi de votre email");
}

Note : Si vous comptez envoyer des emails à des utilisateurs enregistrés sur votre site pensez à utiliser leurs paramètres, comme la langue d’affichage que vous pourrez trouver dans l’objet $user.

Credit photo : JulesAngel