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.

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 à la soumission du formulaire de création de node.

/**
 * 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 créée, il ne reste plus qu’à lui faire 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 redirection depuis Drupal vers des URLs interne ou externe et en passant une série de paramètres. Le seule 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.

$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écidez à 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 !

L’idée pour cette nouvelle version était de se focaliser sur les besoins de la communauté, la réflexion a vraiment placé l’expérience utilisateur au coeur du process. Tous les besoins ont été remontés au travers d’un sondage. Il en est ressorti qu’il fallait améliorer plusieurs choses :

• Gestion des médias
• Intégrer la personnalisation des types de contenu au coeur de Drupal (CCK)
• Editeur de texte riche
• Meilleures performances
• Meilleurs outils pour gérer / structurer le contenu
• Une fonctionnalité proche de Views (mais allégé)
• Mises à jour automatisées
• Amélioration du système d’accès aux noeuds
• Meilleures API internes
• Meilleures API externes (import / export, webservices)
• Utilisabilité

A découlé de ce sondage la mise en place du projet Drupal 7 UX conduit par Mark Boulton et Lisa Reichelt qui ont permis de structurer et conduire le chantier de l’expérience utilisateur pour cette version.

Un nouveau thème est au programme et même deux à vrai dire, « Seven » est le digne successeur de Garland (qui tire sa révérance), et « Stark » est un thème livré par défaut destiné aux themers,  il est construit  avec le strict minimum, idéal pour démarrer votre nouveau thème.

La barre d’administration devient beaucoup plus facile à utiliser car elle migre vers le haut de la page et se voit garnie d’une barre de raccourcis personnalisable.
Des liens contextuels font leur apparition pour effectuer des actions beaucoup plus rapidement.

Majeure évolution, les onglets verticaux font leur apparition, adieu la page qui faisait des kilomètres à scroller, tout est segmenté en onglets maintenant et c’est tant mieux !

Côté insertion de contenu, la gestion des résumés / teaser est améliorée, les formats d’insertion deviennent les formats de texte (plus cohérent) et l’utilisation d’éditeurs de texte riches est facilitée.

L’administration et la navigation en général ont été réorganisés, la gestion des permissions aura maintenant une description pour comprendre chacune d’elle (en plus de nom de permissions plus « user-friendly »). A noter que le rôle d’administrateur fait son apparition de façon native.

Grosse amélioration pour les themers, le contenu, l’aide et le footer deviennent des blocs ! Fini la galère pour themer ces parties et pour les placer là où bon vous semble et c’est d’ailleurs la gestion du contenu globale qui a été revue, tout est maintenant blocs et vous pouvez beaucoup plus facilement choisir les choses à cacher / monter. La gestion des mises à jour a été repensée, vous pouvez maintenant tout effectuer depuis votre tableau de bord (téléchargement et installation).

La personnalisation des types de contenus est maintenant intégrée dans le coeur de Drupal, c’est la Field API (bye bye CCK). Cela veut dire que vous pouvez personnaliser les types de contenus mais aussi les profils utilisateurs, les tags, tout est champ maintenant !

Concernant la gestion des médias, vous pouvez maintenant sans installer de module supplémentaire ajouter des actions sur les images comme le faisait imagecache (miniatures, teinte, etc).

Les contributeurs à la traduction n’ont pas été mis de côté, une des problématiques étant la contextualisation de certains termes qui pouvaient avoir des traductions différentes selon l’action effectuée sur le site s’est vu trouver une solution qui consiste à ajouter un contexte à toutes les chaines de caractères ! Fini les dilemmes cornéliens. L’interface de traduction a été améliorée et la gestion des fuseaux horaires également.

RDF est également au programme, ainsi que l’apparition des tests unitaires pour gagner du temps lors du développement de nouveaux modules  ou de patch pour s’assurer que rien n’est cassé. Une nouveau langage de dialogue avec la base de données basé sur PDO fait sont apparition, un peu rebutant mais très puissant au final. Le support des PostGreSQL est amélioré et la gestion des transactions, des maitres / esclaves et de SQLite est prise en compte. La connectivité aux webservices est améliorée et la gestion des proxies HTTP ont été revues.

Et tout ça, quand est ce qu’on pourra le tester ? A cette question Dries répond que Drupal sortira quand il sortira. Et quand est ce qu’il sortira ? Et bien lorsque le nombre de bugs critiques sera égal à 0. (Actuellement il en reste 408).
L’objectif de Drupal lors des migrations de version est de ne pas casser les données des utilisateurs, le code spécifique peut casser mais pas les données des gens, il y a toujours une façon de migrer leur contenu (plus ou moins simple) mais il existe toujours une façon de mettre à jour une version précédente.

Concernant le portage des modules de la version 6 à la version 7, tous les modules qui comportent le tag #D7CX indiquent qu’ils ont déjà réfléchis à la façon de faire le portage et que la mise à jour sera faite à la sortie de D7 ou dans le mois suivant au plus tard.

Si vous êtes impatients de tester toutes ces nouveautés vous pouvez d’ores et déjà télécharger la version de développement de Drupal 7.

Pour cela, il suffit d’utiliser la requête suivante :

 $query = db_query("SHOW TABLE STATUS LIKE '{node}'");

En remplaçant bien sûr {node} par le nom de votre table. Notez que les accolades sont propres à drupal, cela permet d’ajouter le préfix spécifié par l’utilisateur dans la configuration de la base de données au moment de l’installation.

Cette requête vous retourne un tableau différentes informations sur la table. Je vous invite à consulter la documentation de SHOW TABLE STATUS pour connaître les champs retournés.
Il ne vous reste plus qu’à stocker votre valeur dans une variable pour en faire ce que bon vous semble.

$row = db_fetch_array($query);
$next_id = $row['Auto_increment'];

En espérant que ça servira à certains d’entre vous.

Il existe plusieurs fonction pour vous aider dans votre tache, nous allons les passer en revue.

path_to_theme()

Cette fonction revoit le chemin courant, si vous êtes dans votre thème (sites/all/themes/montheme) ou si vous êtes dans votre module (sites/all/modules/monmodule/monmodule.module).

drupal_get_path($type, $name)

Cette fonction va vous permettre de récupérer le chemin de n’importe quel élément (thème ou module)  et ce qu’importe le fichier dans lequel vous travailler, plutôt pratique ! Il s’utilise de la façon suivante :

// Récupération du chemin vers un module
drupal_get_path("module","views");
 
// Récupération du chemin vers un thème
drupal_get_path("theme","montheme");

L’utilisation de ces deux fonctions vous permet de naviguer dans votre arborescence.

Documentation :

• Fonction drupal_get_path()
• Fonction path_to_theme()

Pour cela, il faut vous rendre sur la page d’administration de FCKeditor (Administrer > Configuration du contenu > FCKeditor)

Pour les profils auxquels vous souhaitez donner les droits en upload, cliquer sur Modifier et dans la partie File Browser settings faire deux choses :

• Passer l’option Allow quick uploads à true
• Sélectionner la méthode d’upload de fichier via l’option File browser type.
  • Si vous sélectionnez « Aucun », l’utilisateur aura juste un champ Parcourir pour envoyer son fichier.
  • Si vous choisissez « Built-in filebrowser » vous pourrez utiliser l’interface de FCKeditor qui permet entre autres de créer des sous-répertoires et de réinsérer des fichiers précédemment uploadés.

Après avoir fait cela il se peut que vous rencontriez le message d’erreur suivant si vous vous jetez sur votre champ de texte pour tester l’upload :

This connector is disabled. Please check the « editor/filemanager/connectors/php/config.php » file.

Pour corriger cette erreur il faut modifier le fichier de configuration de FCKeditor afin d’indiquer où uploader les fichiers sur votre serveur. Le fichier à modifier est le suivant : « sites/all/modules/fckeditor/fckeditor/editor/filemanager/connectors/php/config.php ».

Les modifications à y apporter sont très simples, voilà une portion de code :

// Activer l'upload de fichier en passant la valeur à "true"
$Config['Enabled'] = true ;
 
// Indiquez le chemin relatif à votre DocumentRoot pour uploader les fichiers
$Config['UserFilesPath'] = '/files/' ;
 
// Indiquez le même répertoire que $Config['UserFilesPath']
// mais de façon absolue cette fois.
$Config['UserFilesAbsolutePath'] = '/var/www/lequipe/www/files/' ;

Si un message d’erreur apparait lorsque vous tentez d’uploader un fichier, vérifier le chemin de votre répertoire d’upload (syntaxe et droits d’accès).

Après avoir fait cela vous devriez maintenant pouvoir jouir de l’upload de fichier grâce à votre éditeur de texte riche.

Dans un premier temps il est en général simple de trancher entre CMS et framework, l’un étant adapté pour de la publication de contenu et l’autre étant plus adapté pour des besoins très précis, il faut préférer le framework au CMS lorsque la majorité des fonctionnalités du site ne sont pas couvertes par le CMS.

Mais si l’on doit se tourner vers un CMS, comment trancher ? Il y a beaucoup de produits sur le marché et quels sont les atouts des uns et des autres.

Je vous propose donc de découvrir une présentation que j’ai traduis d’une version anglaise (réalisée par la société finlandaise Exove) qui compare quatre CMS : WordPress, CMS Made Simple, eZ Publish et Drupal.
Pour chaque CMS, les principales qualités et les principaux défauts sont listés, un comparatif est fait avec Drupal et une slide résume dans quelle situation préférer tel ou tel CMS à Drupal.

Cette présentation est amenée à évoluer, l’objectif qui pourrait être utile à Drupal serait d’élargir aux autres principaux CMS du marché afin d’en faire découler un tableau comparatif qui pourra être réutilisé par les commerciaux et autres décideurs lors des avant-ventes de vos projets. Cette démarche peut s’inclure dans le chantier marketing du groupe france de Drupal.

Si vous êtes tenté(e) d’élargir cette présentation foncez publier un commentaire et si le coeur vous en dit, rejoignez le groupe france de Drupal.
N’hésitez pas à vous impliquer ou à impliquer votre société, la communauté a besoin de vous pour grandir.