Aller plus loin avec le module strongarm et le fichier .module de votre feature

Onglets principaux

La documentation Drupal 6 n'est plus maintenue et en cours de dépublication.

Dans les articles précédents j'ai expliqué comme combiner le module Features et le module Context pour pouvoir exporter la configuration de vos modules en un seul module que vous pouvez activer et désactiver à votre guise. Toutefois certaines limites apparaissent rapidement. Et si je veux que mon type de contenu « article_sport » ait par défaut ses commentaires désactivés ? Et comment faire pour exporter la configuration des modules non supportés par Features pour le moment ? Sommes-nous condamnés à fabriquer des features avec "seulement" CCK, views, context, image cache ? Que nenni.

Tirer parti du fichier .module de votre feature

En exportant votre feature, vous obtenez un module Drupal en bonne et due forme, si bien qu'il contient comme il se doit un fichier .module. Par défaut ce fichier contient cette unique ligne (dans mon cas, la feature se nomme « pack_reservation_taxi » ).

<?php
include_once('pack_reservation_taxi.features.inc');
?>

Cette ligne se charge d'aller cherches les autres fichiers de votre module contenant toute la configuration des modules composant votre features sous forme de tableaux php. Mais au-delà de cette ligne, vous êtes libre d'écrire absolument tout ce que voulez comme code php, comme si il s'agissait d'un module Drupal normal. Lors de votre prochain export, votre code fera partie du fichier .module de votre feature ! Voilà qui ouvre de nouveaux horizons.

C'est donc l'endroit idéal pour vous livrer aux hooks en tout genre qui peuvent vous permettre d'aller plus loin dans les ajustements de votre feature et améliorer son exportabilité. On peut imaginer utiliser le hook_enable (qui se déclenche uniquement au moment de l'activation de votre module, et donc de votre feature dans ce cas) pour lancer une requête sql permettant d'ajuster dans la table system le poids d'un autre module de façon automatisée par exemple.

Mais en utilisant le module Strongarm, qui est utilisé sur l'intranet drupal « open atrium » vous pouvez aussi prendre très facilement le contrôle d'une partie très importante de Drupal : les réglages de base des formulaires de configuration de n'importe quel module.

Un peu de théorie : La table « variable » de Drupal

En vous rendant dans la base de données de votre installation Drupal avec phpmyadmin ou autre, vous pourrez constater la présence d'une table variable. Cette table joue un rôle majeur dans la configuration de vos modules -et donc de votre site. En effet, chaque fois que vous vous rendez dans un formulaire de configuration d'un module, quand vous appuyez sur le bouton enregistrer, c'est dans cette table que sont stockés vos changements. Autrement dit, si nous pouvions exporter dans notre feature certaines variables de cette table, ça nous permettrait de maîtriser la configuration par défaut de n'importe quel module Drupal possédant une page d'administration lors de l'activation de notre feature.

Le module strongarm

C'est très justement ce que se propose de faire le module Strongarm. Ce module ne propose pas d'interface utilisateur, c'est au développeur d'implémenter un hook permettant de spécifier la configuration qu'il souhaite pour tel ou tel module Drupal. Une place toute trouvée pour implémenter ce hook c'est le fichier .module de votre feature :-)
Voici un exemple concret de ce hook que j'ai implémenté dans ma feature « pack_reservation_taxi », pour laquelle je souhaitais que soient désactivés par défaut les commentaires sur deux types de contenus spécifiques. Je souhaitais également que le module « automatic node title » soit automatiquement configuré pour cacher le titre de ces types de contenus et les remplacer par des tokens de mon choix. Plutôt que de refaire cela à la main lors de l'import de ma feature, j'ai implémenté le hook_strongarm, (disponible une fois activé le module Strongarm).

<?php
 
function pack_reservation_taxi_strongarm() {
 
$conf = array();

 
// Désactiver les commentaires sur les types de contenus fiche trajet et vehicule
 
$conf['comment_fiche_trajet'] = COMMENT_NODE_DISABLED;
 
$conf['comment_vehicule']     = COMMENT_NODE_DISABLED;
 
 
//autonodetitle
 
$conf['ant_fiche_trajet'] = 1; //cacher automatiquement les titres
 
$conf['ant_pattern_fiche_trajet'] = '[field_ville_depart-title] > [field_ville_arrivee-title]'; //tokens

 
return $conf;
}
?>

Une fois ce hook implémenté, vous pourrez voir (après avoir vidé le cache de Drupal) sur les types de contenus choisis que les commentaires sont automatiquement forcés à « disabled ». De plus, le module Strongarm vous affiche un message vous indiquant que des champs de ce type de contenus sont « forcés » par Strongarm. Les boutons radios pour changer la configuration des commentaires apparaîtront dans un cadre de couleur et seront grisés : vous ne pouvez plus les changer. Toutefois en vous rendant dans la page de configuration du module Strongarm, vous pouvez décider qu'il reste possible d'overrider ces réglages, en dépit des ordres donnés par votre hook.

En utilisant à bon escient le fichier .module de notre feature et Strongarm, nous disposons donc d'un sérieux arsenal pour contrôler une grande partie de la configuration de vos modules avec peu d'efforts.

Version de Drupal : 

Commentaires

Que de complications, nyl auster !

Alors qu'il suffit des lignes

<comment>0</comment>
<ant>1</ant>
<ant_pattern>[field_ville_depart-title] > [field_ville_arrivee-title]</ant_pattern> 

dans l'action <content> (celle qui crée le content type) d'un pattern ! Pourquoi aller prendre l'avion de Orly à Saint-Exupéry quand un simple TGV Paris-Lyon fait aussi bien l'affaire ? Et devoir en plus entretenir l'avion derrière !

Une petite correction si tu permets :
En vous rendant dans la base de données de votre installation Drupal avec phpmyadmin ou autre, vous pourrez constater la présence d'une table variable. Cette table joue un rôle majeur dans la configuration de vos modules -et donc de votre site. En effet, chaque fois que vous vous rendez dans un formulaire de configuration d'un module, quand vous appuyez sur le bouton enregistrer, c'est dans cette table que sont stockés vos changements.

Autant que je sache, ça dépend des modules : les modules les plus importants utilisent des tables à eux. Les paramètres d'ANT reposent en effet sur la table variable. Mais Flag, par exemple, n'est absolument pas piloté par elle. Si ce hook strongarm ne travaille que sur la table variable de Drupal, cela limite son champ d'action.

Peux-tu examiner cela et dire à une non-développeuse-incapable-d'utiliser-un-hook ce qu'il en est ?

Hello
Je n'ai pas le temps de répondre à toutes les objections, j'y reviendrais plus tard. Concernant Strongarm ce n'est pas vraiment une limitation puisque qu'il ne prétend pas faire autre que de gérer cette table. Effectivement tous les modules ne passent pas par la table variable mais ça reste un point névralgique pour beaucoup de paramètres.
edit : pour ceux qui ont des tables à part, c'est features qui est censé les prendre en charge (cf CCK et views par ex)

"
Que de complications, nyl auster !

Alors qu'il suffit des lignes

<ant>1</ant>
<ant_pattern>[field_ville_depart-title] > [field_ville_arrivee-title]</ant_pattern>

"

c'est un peu subjectif vu que je suis dev, je ne trouve pas que ce code php soit beaucoup plus complexe
"

<?php
  $conf
['ant_fiche_trajet'] = 1; //cacher automatiquement les titres
 
$conf['ant_pattern_fiche_trajet'] = '[field_ville_depart-title] > [field_ville_arrivee-title]'; "
?>

Mais comme je disais sur twitter, je propose juste des explications sur le fonctionnement de features, je ne prétends pas que ce soit la solution ultime. Je mets du matériel à disposition pour que les gens puissent faire leur choix. j'ai bien l'intention de tester patterns également, et les autres dans ce genre. Features m'intéresse beaucoup parce que j'aime la manière dont est structuré open atrium.