CPH 2010 : Drupal distros dos and don'ts

Cette conférence était menée par Jeff Miccolis de Development Seed et Irakli Nadareishvili de Phase2 Technology, l'un et l'autre sont à la tête d'une armée de développeurs ayant formé deux distributions, ayant une renommée dans l'écosystème Drupal, respectivement Open Atrium et Open Publish.

On peut résumer cette conférence comme étant une retour d'expérience assez rapide sur les différentes problématiques auxquelles ont été confrontées ces deux sociétés. Je ne vais pas répéter l'ensemble de ce qui à été dit, mais plutôt m'arrêter sur les problèmes qui semblent être redondants.

Ces deux protagonistes s'entendent à définir une distribution Drupal comme étant un package, reposant sur le core, s'installant de manière atypique à l'aide d'un profil d'installation particulier, dont le but est de répondre à un besoin spécifique. En ce qui concerne l'installation atypique, on notera cette volonté de ne jamais laisser l'utilisateur final devant un écran vide de sens - a contrario de Drupal core nu - depuis le début de la procédure d'installation, jusqu'à sa première utilisation du site. La notion de get rid of Drupal-isms que l'on peut traduire par se débarasser des Drupalismes a été employée à ce sujet, elle est très parlante.

Note personnelle à ce propos : je ne suis pas d'accord quant à l'emploi de cette expression, Drupal a certes beaucoup de défauts mais les Drupalismes sont en réalité beaucoup plus présents pour les développeurs et intégrateurs que pour les utilisateurs finaux. On notera que cette expression a été utilisée lors de plusieurs conférences, dans des contextes souvent bien différents.

Ne pas reposer sur le profil pour la configuration

Un des premiers problèmes évoqués semble être celui du profil d'installation. Drupal 6 est assez pointilleux quant au fonctionnement de sa procédure d'installation, et mettre en place un profil complet semble être de l'ordre de l'impossible, l'API fournie pour créer des profils étant quasiment inexistante. Il a été relaté le fait que Drupal 7 va changer la donne concernant ce dernier point.

La raison la plus évidente d'éviter de reposer sur un profil d'installation est que ce dernier ne supporte pas de mécanisme de mise à jour. L'implémentation des fameux hook_update_N() présent pour les modules n'est pas possible pour un profil, ce qui implique que toute configuration effectué lors de cette phase ne pourra pas être sujete à mise à jour, et obligera l'utilisateur d'un site à le réinstaller complètement s'il veut pouvoir profiter d'une mise à jour. Ce qui nous amère au second point.

Laissons au modules ce qui appartient aux modules

Comme précisé ci-dessus, les modules bénéficient de l'API de mise à jour de Drupal, ce qui est un premier point très important. Par conséquent, le processus de mise à jour d'une distribution peut tout à fait reposer sur l'ensemble des processus de mise à jour de ses modules. De plus, procéder comme suit permet d'isoler les problèmes par module. Je suis particulièrement d'accord sur ce point ; étant actuellement en train de travailler sur un projet client conséquent depuis environ six mois, dont le but affiché est à terme d'en faire une distribution.

La notion d'exportables revient souvent dans la conférence, un exportable est souvent employé comme un concept assez vague. Les deux acteurs s'entendent - une fois encore - sur la définition du concept : ils mélangent les genres tout deux en définissant le concept comme pouvant être à la fois la configuration d'un ensemble fonctionnel (que ce soit des variables, ou la création de views particulières par exemple), ou comme étant un certain nombre d'objets présents par défaut sur le site (des contenus ou vocabulaires). La première de ces deux définitions prévaut bien souvent la deuxième, et la notion prend tout son sens dans ce cas.

Un des gros problèmes de Drupal est que sa configuration réside quasi intégralement dans la base de donnée, ce qui pose de très gros soucis pour procéder aux mises à jour de cette dernière. Pour répondre à ce problème les exportables vont intervenir. Le module Features de Development Seed semble avoir été choisi à l'unanimité pour répondre au besoin, il semble être choix logique quand on connait l'état actuel de l'écosystème des modules contribués de Drupal.

Les features sont bien entendu des modules à part entière, en conséquence ils peuvent être versionnés à volonté. On retrouvera donc aussi la possibilité d'implémenter la mise à jour de la distribution dans ces derniers.

Note quant à Features

Quelque chose ici est assez important, tout deux préconisent de toujours grouper la configuration de la distribution Drupal par espaces fonctionnels, si possible indépendants les uns des autres. Chaque espace fonctionnel sera l'objet d'un module basé sur Features.

Petit détail amusant, il s'avère que personne n'échappe à la méthode de La Rache. Tout le monde fini un jour ou l'autre par faire un module intégralement dédié à peaufiner la configuration d'un site, ne portant rien d'autre que quelques altérations de formulaire qu'on ne sait mettre ailleurs, ainsi que des procédures d'installation et de mise à jour spécifiques au site. Ceci est bien entendu le cas pour ces deux distributions majeures.

Et ensuite ?

Ceci est une présentation assez générale des choix architecturaux des deux acteurs pour la création et la maintenance à long terme d'une distribution Drupal. La conférence ne s'est pas arrêtée là, je dois vous avouer que cet article ne reflète environ qu'un tiers de la feuille de papier qui se trouve devant moi. La suite est plus technique, et pour un certain nombre de choses qui se trouvent à l'intérieur, seront accompagnés de critiques plus vives - non pas destructives, mais en tout cas subjectives et probablement constructives - et sera le sujet d'un nouvel article à venir.

A bientôt!

Votre notation : Aucun Moyenne : 5 (521 votes)