Introduction aux modules Features, Spaces et Context

Onglets principaux

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

Ceux qui ont suivi le lancement du projet Open atrium ( http://openatrium.com/ , un distribution drupal pour créer un intranet) auront sans doute entendu parler du trio de modules context, spaces et surtout features; autour desquels est structuré ce projet.

Il existe encore peu de documentation à ce sujet, voici donc un bref aperçu permettant de saisir dans les grandes lignes l'intéret, et le potentiel énorme de ces modules. Notons tout de même avant toute chose que le module features est plutôt destiné aux professionnels de Drupal.

Voir aussi :

A quoi sert features ?

La pierre angulaire d'open atrium est le module features, qui tente d'accomplir deux nobles objectifs : - faciliter le déploiement de projet drupal (réutilisabilité / transportabilité accrues) - faciliter le "staging" ("comment que je mets mon site en ligne à jour sans écraser la base de données et donc perdre le contenu rentré entre temps par mes visiteurs ??" )

En dehors de ces deux objectifs fort louables, on peut se risquer à dire qu'en plus, le paradigme proposé par features n'est pas sans élégance, mais nous y reviendrons.

Un peu de théorie

Features peut être considéré comme une "couche supplémentaire" de Drupal. Jusqu'ici on pourrait théoriser (à la hache) Drupal comme étant constitué en 3 niveaux principaux.

  • PHP : le langage dans lequel est codé Drupal
  • API de Drupal : codée en PHP, elle offre une librairie de fonctionnalités faciles à manipuler pour faciliter le développement de module (systeme de theming, hooks, tout ça)
  • Modules : bâtis sur l'API, ils permettent de répondre à un certain besoin utilisateur. Ce niveau est le plus facile à manipuler puisqu'il ne nécessite pas de connaissances en php pour être mis en place

A partir de là, il est intéressant de noter que plus le temps passe, et plus drupal tends à nous fournir des modules qui ne sont que des petites briques, qui combinées à d'autres petites briques, permettent de reconstruire soi-même une macro-fonctionnalité / un besoin utilisateur. Par macro-fonctionnalité, j'entends par exemple : un gestionnaire de tâches, un blog, un forum ...

Par exemple les champs CCK, le module views, le module node reference sont des modules qui ne fournissent aucune fonctionnalité en eux même, en revanche ils vous permettent de créer , avec de l'huile de coude tout de même, un systeme multiblog, un gestionnaire de taches ... bref ce sont des legos techniques à la disposition de votre imagination délirante de drupalien fou. C'est d'ailleurs pour cela que drupal, plus qu'un CMS, est un CMF (content management framework).

Mais une fois toutes les vues, champs cck , blocs etc... crées pour notre macrofonctionnalité qui tue la mort, se pose une question terrible s'il en est : et si je veux refaire cette fonctionnalité sur un autre site ensuite ? il faut refaire toutes les vues, tous les champs CCK, que je replace tous mes blocs un par un ? Votre pomme d'adam s'étreint d'émotion à l'évocation de cette hypothese peu ragoutante.

Halte là ! features vous propose une solution : "enregistrer" et capturer, en quelques clics toute votre travail de configuration dans un module. Il vous suffira ensuite d'installer votre module sur une install vierge de drupal et ô joie ! toutes vos vues , vos champs CCK, vos blocs, vos presets imagecache se recréent tous seuls comme par magie. Features vous permet de "packager" vos configurations puis de les importer sur un autre site. Plus que ça, features fait de son mieux pour que votre configuration puisse en plus vivre "dans le code" uniquement, c'est à dire que votre vue peut parfaitement être utilisable en étant bien au chaud dans un hook, dans le code de votre module. Il n'est pas nécessaire qu'elle soit enregistrée dans une BDD. On retrouve donc doucement l'idée que la base de données doit servir à enregistrer le contenu de l'utilisateur tandis que la configuration reste dans le code.

Une autre approche de Drupal avec Features

Le module Features se propose donc d'ajouter un nouveau niveau à Drupal, qui ressemble alors à ceci :

  • PHP
  • API
  • Modules
  • Features

En combinant différents modules, on peut obtenir une fonctionnalité précise que l'on peut packager dans une features. Hélas, la portée de features reste encore relativement limité sur Drupal 6, la liste des modules compatibles étant plutôt restreinte : views, cck, context, panels, imagecache, menu, les droits d'accès (j'en oublie sans doute deux ou trois)

Néanmoins ne jetons pas le bébé avec l'eau du bain : si features est loin d'être la solution idéale, c'est aussi une des solutions les plus prometteuses et élégante de ce côté. De plus, malgré le nombre de module assez restreint supporté, cela reste toutefois suffisant pour construire de très jolies features. Open atrium reste une bonne démonstration des possibilités de ce paradigme. Enfin, il ne faut pas oublier qu'il est tout à faire possible de rajouter du code php dans une features puisqu'il s'agit d'un module comme un autre, si ce n'est que son fichier .info contient des informations permettant d'importer automatiquement des vues, des champs CKK etc...

Spaces

La notion d'espace est liée à celle de feature : une feature peut être activée, désactivée pour un espace particulier : ainsi si vous utilisez organic groups + spaces, vous pouvez proposer à chaque groupe d'activer ou de désactiver des features selon leur besoins, et cela indépendamment des autres types de groupe. Open atrium fonctionne principalement avec des espaces pour les organic groups et apparemment pour les profils (user-spaces).

Physiquement, la notion d'espace est en fait liée au module "purl" qui permet d'ajouter un préfixe à vos url. Ce préfix permet de déclencher l'espace et tous les paramètres de context ou des vues qui peuvent être sensibles aux espaces.

Exemple : avec user-space, l'url de votre compte devient "space-votrepseudo/user".

La notion d'espace est toute indiquée pour la gestion d'un intranet en particulier et a probablement été spécifiquement conçue pour ce besoin particulier, mais on peut imaginer bien d'autres applications, d'autant que spaces 3 promet (encore) une petite révolution conceptuelle.

Context

Context est un module permettant de facilement regrouper des éléments de configuration d'une feature. Exemple concret : si vous voulez faire une feature de blog, vous souhaitez que fasse partie de votre feature :

  • une vue listant vos derniers billets
  • un bloc listant les derniers commentaires
  • que ce bloc apparaissent sur les types de contenus blogs et peut être aussi sur la vue

Qui n'a jamais révé d'expliquer par exemple simplement à Drupal que la vue listant vos types de contenu news fait partie de la même section du site que vos node news ? Et qu'il est en conséquence logique que votre item de menu "news" soit en surbillance quand vous vous trouvez sur la page de liste de news ? C'est typiquement ce genre de problématique à laquelle s'attaque context.

Context est un module permettant de centraliser et d'exporter tous ces paramètres de configuration et donc devient un élément clef pour composer votre feature. En général, pour composer votre feature vous avez besoin d'un contexte permettant de choisir quel blocs et vue font partie de votre feature, comment ils sont positionnés (plus d'autres paramètres intéressants proposés par context). Nulle obligation de passer par contexte, mais cela facilite la construction de votre feature.

Vous pouvez ensuite exporter dans la feature (en créant la feature dans le menu feature) en prime bien d'autres choses intéressantes comme un type de contenu, des champs CCK, un élément de menu, une permission utilisateur etc...

Impact sur votre workflow de production

Vous venez de changer une vue en local et vous souhaitez voir le résultat sur votre serveur de production ? si votre vue fait partie d'une features et que vous utilisez l'excellentissime module drush (si vous ne le connaissez pas, foncez tout de suite le télécharger), il vous suffit de mettre à jour votre features en une ligne de commande : - drush features-update votre_features

pour mettre à jour dans votre code la vue. Plus qu'à commiter sur le serveur de prod pour voir le résultat ! Utiliser drush et features reste le moyen le plus rapide et efficace de mettre le maximum de configuration dans le code et l'exporter / mettre à jour avec facilité. (une ligne de commande drush, y'a pas plus rapide, plus qu'à se préparer une tisane pendant votre "features-update-all").

Inconvénients du module Features :

  • Tous les modules ne permettent pas d'être capturés par features; et cette logique de feature ne fait pas partie de la logique du coeur de Drupal. Ca reste donc une solution intéressante mais pas pleinement implémentée et fonctionnelle dans Drupal. Les modules doivent notamment implémenter certains hooks pour être découverts par features et disposer idéalement d'une configuration exportable/importable en php (comme le module views possède cette possibilité d'export); ce qu'ils ne proposent pas tous.

Ressources (anglais seulement, désolé !)

Version de Drupal : 

Commentaires

merci nyl, super cool de lire un peu de français sur le "trio" à la mode ...
++

robin
http://gazwal.com - Expertise Drupal & Intégration Web / Freelance
http://biboo.net - Tutoriels vidéos Drupal
http://twitter.com/gazwal

robin
http://gazwal.com - Expertise Drupal & Intégration Web / Freelance
http://biboo.net - Tutoriels vidéos Drupal
http://twitter.com/gazwal