La cause du problème était pourtant sous mes yeux depuis le début, dans la barre d’adresse, ce petit préfixe qui traîne et qui ne paie pas de mine, en remplaçant le ‘fr’ par un ‘en’ ou en le supprimant, le problème s’est résolu.

Pensez-y si le problème vous arrive, la négociation de langue n’est pas compatible avec simpletest.

Si vous vous retrouvez dans la situation où vous ajoutez une fonction de validation sur un formulaire mais que cette fonction n’est pas exécutée (et que bien sûr vous avez vérifié par trois fois la syntaxe de votre code), prenez le temps de regarder le détail du formulaire.

En fait il faut savoir que lorsque vous cliquez sur un élément de formulaire de type bouton, ses fonctions de validation et d’exécution sont exécutée et seulement celles de ce bouton. Ce qui au final est logique car cela vous permet d’avoir un comportement différent par bouton sans avoir de risque d’interférences entre les fonctions de validation / exécution de votre bouton et celles du formulaire global. Le détail des mécanismes de ces fonctions à exécuter se trouve dans la fonction form_execute_handlers().

A noter également qu’il existe un attribut du Form API qui a été introduit dans Drupal 7 qui permet de limiter les valeurs à contrôler lors de la soumission du formulaire, il s’agit de l’attribut #limit_validation_errors. Cet attribut prends un tableau comme valeur avec la liste des entrées du $form_state['values'] qui doivent être validées. Pratique pour contourner un champ obligatoire lorsque l’on a un bouton qui supprime un noeud par exemple.

Nous allons donc voir comment exposer vos propres événements, conditions et actions à Rules. Rules est très flexible et offre la possibilité par défaut de rajouter les briques dont vous pourriez avoir besoin pour vos développements.

Commençons par les événements qui déclenchent les rules. Nous allons déclencher un événement lorsqu’un type de contenu précis sera visualisé, nous pourrions le faire avec les composants de base de Rules mais cela permet d’avoir un exemple assez simple. N’hésitez pas à consulter la documentation rédigée par fago pour rules, elle est assez complète et à jour.

Pour déclarer un événement il suffit d’implementer le hook hook_rules_event_info() et de décrire tous vos événements avec leurs paramètres. Exemple :

Source code

<?php
/**
* Implements hook_rules_event_info().
* Déclaration d'un événement basé sur le type du node vu.
*/
function monmodule_rules_event_info() {
  return array(
    'nodearticle_is_viewed' => array( // Nom de l'événement à invoquer via Rules.
      'label' => t("Un node de type article est entrain d'être vu"), // Description de la rule.
      'module' => 'Mon Module', // Groupe dans lequel faire apparaitre l'événement (node, utilisateur ou mon module).
      'arguments' => array( // Tableau des paramètres à passer à la fonction.
        'article' => array('type' => 'node', 'label' => t('Article visualisé.')), // Ici seulement le node.
      ),
    ),
  );
}
?>

Pour que l’implémentation de l’événement soit complète il ne reste plus qu’à signaler à rules que l’événement se produit. Pour cela il suffit d’appeler la fonction rules_invoke_event() au bon moment. Dans notre exemple il suffit de faire cela au sein du hook_nodeapi() si le node est affiché et qu’il a le type article.

Source code
   
/**
* Implements hook_nodeapi().
*/
function monmodule_nodeapi(&$node, $op) {
  if ($op == 'view' && $node->type == 'article') {
    rules_invoke_event('nodearticle_is_viewed', $node); // Invocation de l'événement.
  }
}

Regardons maintenant comment déclarer de nouvelles conditions, l’exemple ici consiste à déterminer si le node que nous sommes entrain de visualiser possède un champ CCK précis (de type nodereférence )avec une valeur.

Cette fois ci il faut implémenter le hook hook_rules_condition_info() pour arriver à nos fins. Comme d’habitude un exemple est plus parlant.

Source code

/**
 * Implements hook_rules_condition_info().
 */
function monmodule_rules_condition_info() {
  return array(
    'monmodule_has_nodereference' => array(
      'label' => t('Mon node a un node référence.'),
      'arguments' => array(
        'node' => array('type' => 'node', 'label' => t('Node à vérifier')),
      ),
      'module' => 'User',
    ),
  );
}

Comme pour la déclaration d’un événement, les conditions font appel à une fonction de callback, ici monmodule_has_nodereference. Dans cette fonction nous allons implémenter concrètement effectuer le test de la condition à évaluer.

Source code

function monmodule_has_reference($node, $settings) {
  if (isset($node->field_book)) {
    if (!is_null($node->field_book[0]['nid'])) {
      return TRUE;
    }
  }
  return FALSE;
}

Ici nous évaluons la valeur d’un éventuel node reference pour le champ field_book mais le nom de ce champ pourrait être exposé dans la configuration de la condition, cette valeur se retrouverait dans le paramètre $settings. Pour voir comment configurer les conditions et actions, reportez à la documentation.

Une fois que les événements et conditions sont là, il ne reste qu’une chose à faire, écrire le code qui va être exécuté une fois notre évènement déclenché et notre condition remplie. Vous l’avez compris cette fois il faut exposer cette action via le hook hook_rules_action_info().

Source code

/**
 * Implements hook_rules_action_info().
 */
function monmodule_rules_action_info() {
  return array(
    'monmodule_domyaction' => array(
      'label' => t('Effectuer mon traitement'),
      'arguments' => array(
        'node' => array('type' => 'node', 'label' => t('Node exposé')),
      ),
      'module' => 'Mon Module',
    ),
  );
}

Et toujours sur le même principe, la fonction de callback que vous avez déclaré est appelée lorsque la rule est déclenchée et satisfait les conditions configurée.

Source code

function monmodule_domyaction(&$node) {
  drupal_set_message(t("Ce noeud est de type article et possède au moins un node comme node reference dans le champ field_book"));
  // Effectuer tous les traitements imaginables.
}

Etendre Rules 1 est donc quelque chose de très simple, tout se passe principalement dans ces trois hooks et grâce à eux vous pouvez étendre les possibilités de Rules à l’infini. N’hésitez pas à consulter la documentation pour découvrir d’autres fonctionnalités offertes par Rules.

Rules 2 (Drupal 7)  permet d’utiliser Rules comme une API de façon beaucoup plus simple,  cette nouvelle version explore très facilement les types d’entités et si vous installé entity metadata, vous pourrez également exploiter la puissance des informations additionnelles mises à disposition (accès à toutes les données d’un type d’entity).

Rules est un module développé par Wolfgang Ziegler AKA fago et est simplement une pure merveille et ça ne serait pas surprenant qu’il soit intégré à core sur Drupal 8 en remplacement de trigger et action. Rules était puissant sous Drupal 6 et l’est encore plus sous Drupal 7 (enfin là !).

Ensemble nous allons construire quelques rules simples via l’interface de Drupal et une action « custom » en implémentant les hooks à notre disposition.

Définition : Une rule représente une ou plusieurs actions réalisées lorsqu’une ou plusieurs conditions sont remplies suite au déclenchement d’un événement.

Trois termes clés ressortent ici :

Condition
Une condition peut être le test d’une valeur d’un champ CCK, le rôle d’un utilisateur, le type d’un node, la valeur de l’URL, la force de Rules est que chaque module peut étendre les conditions disponibles avec par exemple Organic Groups qui donne la possibilité de tester si l’utilisateur est membre d’un groupe.
Les conditions peuvent être multiples et peuvent être groupées et combinées via des opérateurs logique (ET et OU).

Action
Une action est une opération à executer lorsque les conditions listées précédement sont toutes remplies. Charger un noeud, envoyer un email, afficher un message, attribuer un rôle et dépublier un node sont des exemples d’actions possibles. Les actions pouvant être executées sont elles aussi extensibles par les modules contrib.
Les actions peuvent être multiples.

Evénement
Un événement est une opération qui déclenche l’évaluation des conditions d’une rule. Exemples possibles : un node est visualisé, un commentaire est publié, un utilisateur se connecte, etc. Les événements sont eux aussi extensibles par les modules contrib.

Un exemple complet d’une rule serait donc d’attribuer le rôle contributeur à un utilisateur lorsqu’il soumet un node de type article.

La puissance de Rules réside dans le fait que les actions peuvent se combiner et les conditions peuvent s’additionner pour donner des rules très complexes.

Note : Ceux qui ont déjà travaillé avec Ubercart et les predicats retrouveront des similitudes avec Rules.

Il faut ajouter aux conditions, actions et événements un élément clé supplémentaire, les arguments. Lorsque l’on veut évaluer une condition sur le rôle de l’utilisateur, il est nécessaire d’avoir l’objet utilisateur à disposition. Lorsque l’on veut tester le type d’un node, il fait avoit l’objet node à disposition. L’utilisateur ou le node sont donc les arguments utilisés dans l’évaluation des conditions ou des événements. Les arguments à transmettre dépendent du déclencheur que vous avez configuré pour lancer l’évaluation d’une rule. Lorsqu’une action ou une condition que vous aimeriez utiliser dans votre rule n’est pas disponible, cela signifie que vous n’avez pas à disposition l’argument dont vous avez besoin (exemple : vous voulez tester le type du node alors que vous avez utilisé l’événement de déclenchement de la rule « lorsque l’utilisateur se connecte », vous avez à disposition l’utilisateur alors que vous voulez utiliser le noeud). La solution dans ces cas là est d’utiliser un rules set.

Le rules set est un ensemble de rules à executer. Les rules sets peuvent être utilisés lorsque les actions doivent être programmées dans le temps, exemple : dépublier tous les lundi les articles de la page d’accueil datant de plus d’une semaine. Les rules sets ont l’avantage de pouvoir cumuler les arguments (utilisateur, noeud, taxonomie, etc) et donc d’élargir les conditions et actions pouvant être executées.

Partie 2 sur les rules implémentées programmatiquement à venir.

Implémenter une telle fonctionnalité relève de l’ordre du theming, vous cherchez à afficher un formulaire d’une façon particulière et les éléments que vous voulez réordonner vont devoir être themés comme un tableau. La fonction qui nous intéresse pour arriver à nos fins s’appelle drupal_add_tabledrag(), elle est appelée au sein d’une fonction de theming que l’on applique à l’élément de formulaire qui englobe vos éléments à réordonner, regardons un peu de code :

/**
 * Implements hook_theme().
 */
function module_reorder_text_theme($existing, $type, $theme, $path) {
 return array(
 'MODULE_reorder_text' => array(
 'arguments' => array($form => NULL),
 ),
}

Il faut donc dans un premier temps déclarer votre fonction de thème. Cette fonction sera directement appliquée à un élément du formulaire comme suit :

function orderable_form($form_state) {
 $form = array();
 $form['#theme'] = 'module_reorder_text';
}

Regardons maintenant plus en détails le contenu de la fonction de thème :

function theme_module_reorder_text($form) {
 // Titre des colonnes du tableau à trier
 $header = array('', t('Weight'), t('Content'));
 // Ajout du comportement "triable" sur le tableau qui a l'ID "sortable-table"
 // Order signifie que les éléments seront triables voir la documentation pour les autres comportements
 // Sibling : comportement à utiliser sur les éléments du tableau
 // sortable-weight est un nom de classe à utiliser sur les champs qui sont liés dans le tableau
 drupal_add_tabledrag('sortable-table', 'order', 'sibling', 'sortable-weight');
 // $form['items'] est un tableau d'éléments à trier, cet élément de tableau a sa propriété #tree à TRUE.
 foreach ($form['items'] as $key => $value) {
  $value['weight']['#attributes']['class'] = 'upload-weight';
  // Il est nécessaire d'utiliser la fonction drupal_render() pour afficher le champ en HTML
  // Le javascript va remplacer le champ weight par des éléments qui peuvent être glissés / déposés pour réorganiser le tri.
  $row = array('', drupal_render($value['weight']), drupal_render($value['text']));
  $rows[] = array('data' => $row, 'class' => 'draggable');
 }
 $output .= theme('table', $header, $rows, array('id' => 'sortable-table'));
 return $output;
}

Le vrai point important ici consiste à utiliser la fonction drupal_render() pour afficher le contenu des éléments du tableau.
C’est vraiment grâce à ce genre de petits détails que Drupal devient toujours plus indispensable. Merci Drupal !

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 :

 '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.

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

 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.

", $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.

');
}
?>

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.

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.

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.

function openatrium_profile_tasks(&$task, $url) {
 global $profile, $install_locale;

 // Just in case some of the future tasks adds some output
 $output = '';

 // Download and install translation if needed
 if ($task == 'profile') {
 // Rebuild the language list.
 // When running through the CLI, the static language list will be empty
 // unless we repopulate it from the ,newly available, database.
 language_list('name', TRUE);

 // If we reach here, means no language install, move on to the next task
 $task = 'intranet-modules';
 }

 // We are running a batch task for this profile so basically do nothing and return page
 if (in_array($task, array('intranet-modules-batch', 'intranet-translation-batch', 'intranet-configure-batch'))) {
 include_once 'includes/batch.inc';
 $output = _batch_page();
 }

 // Run additional configuration tasks
 // @todo Review all the cache/rebuild options at the end, some of them may not be needed
 // @todo Review for localization, the time zone cannot be set that way either
 if ($task == 'intranet-configure') {
 $batch['title'] = st('Configuring @drupal', array('@drupal' => drupal_install_profile_name()));
 $batch['operations'][] = array('_openatrium_intranet_configure', array());
 $batch['operations'][] = array('_openatrium_intranet_configure_check', array());
 $batch['finished'] = '_openatrium_intranet_configure_finished';
 variable_set('install_task', 'intranet-configure-batch');
 batch_set($batch);
 batch_process($url, $url);
 // Jut for cli installs. We'll never reach here on interactive installs.
 return;
 }  

 return $output;
}

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

1. profile
2. intranet-modules
3. intranet-modules-batch
4. intranet-configure
5. intranet-configure-batch
6. 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.

Vos désirs sont des ordres ! Petit tour de magie très simple pour accomplir une telle action.

Dans un premier temps il nous faut ajouter une fonction de traitement à exécuter lorsque le formulaire de création de node est soumis.

/**
 * Implementation of hook_form_alter().
 * Ajouter une fonction qui redirige l'utilisateur automatiquement
 * vers le formulaire de création de contenu d'un autre type mon utilisateur
 */
function MONMODULE_form_alter(&$form, &$form_state, $form_id) {
 // Ajouter notre fonction si le formulaire est un formulaire
 // de création de noeud et si le type de contenu créé est un article
 if ($form["#id"] == 'node-form' && $form["type"]["#value"] == "story") {
  $form["#submit"][] = 'MONMODULE_create_submit';
 }
}

Notre fonction est déclarée auprès du formulaire de création de noeud, il ne reste plus qu’à implémenter cette fonction qui va faire la redirection.

/**
 *  Rediriger vers le formulaire de création de sondages
 */
function MONMODULE_create_submit($form, &$form_state) {
 $_REQUEST['destination'] = 'node/add/webform';
}

Et le tour est joué ! C’est aussi simple que ça.
Un peu d’explications, pour faire une redirection depuis un formulaire il existe plusieurs méthodes.

drupal_goto()

Cette fonction permet de faire des redirections depuis Drupal vers des URLs internes ou externes en passant une série de paramètres. Le seul détail qui fâche c’est que drupal_goto() stoppe complètement l’exécution du script en effectuant la redirection. Si un traitement devait se faire après l’exécution de votre fonction vous pouvez faire une croix dessus.

$form['#redirect']

Cette méthode permet d’ajouter une redirection après le traitement du formulaire, cette technique peut être utilisée à la création du formulaire ou depuis un hook_form_alter(). Si vous ne pouvez travailler que dans une fonction supplémentaire au moment de la soumission du formulaire cette technique ne peut être employée. Si la fonction de soumission du formulaire exécutée par defaut définie une autre valeur pour $form['#redirect'] votre valeur sera ecrasée.

$form_state['redirect']

Cette fois, si vous ne pouvez travailler que dans une fonction supplémentaire à la soumission du formulaire cette technique fonctionne, vous écrasez la valeur définie dans $form['#redirect'] pour renvoyer l’utilisateur là où vous l’avez décidé à la fin du traitement de votre fonction. Cette technique ne fonctionne en revanche pas lorsque le formulaire que vous modifiez est le formulaire de création de noeud.

$_REQUEST['destination']

Pourquoi devoir employer cette méthode ? Il faut savoir qu’à la création d’un noeud la dernière fonction appelée est toujours node_form_submit(). Cette fonction fixe la valeur de $form_state['redirect'] à node/NID pour rediriger l’utilisateur vers le noeud qui vient d’être créé. La seule façon propre de détourner cette action est donc de recourir à $_REQUEST qui est l’unique option de passer outre les valeurs définies dans $form et $form_state.

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

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

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

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

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