Drupal, Feature, Context, Views, mais pourquoi faire simple ?

La semaine dernière un de mes clients m'a commandé une modification sur son site sous Drupal pour lequel il avait avec un "très léger" souci de maintenance... Ce site étant réalisé par une vraie société maîtrisant les "best-practice Drupal" (Views et tout le tremblement), j'ai pensé m'en sortir vitesse grand V... Et pourtant, six heures plus tard j'y suis encore. Tellement abasourdi que j'ai besoin de l'écrire.

Navigation simplissime

Le site en question n'a rien de sorcier. Juste une base d'article tout ce qu'il y a de plus standard, et comme seul "exotisme", un menu principal piloté par une taxonomie arborescente à deux niveaux (rubrique/sous-rubrique). Le principe de navigation est assez simple, un menu principal reflète la taxonomie (menu déroulant donc):

• On clique sur la rubrique, cela donne accès une mini-page d'accueil avec trois articles en avant.
• On clique sur la sous-rubrique, et là on arrive sur la liste des articles comportant le terme de taxonomie correspondant.

Pour en venir au petit pépin de mon client, le site qu'on lui a livré marche parfaitement à un détail près, impossible d'ajouter une nouvelle rubrique/sous-rubrique. Pour ajouter les termes dans le vocabulaire adéquat, pas de soucis, mais pas de menu non plus. Il a bien essayé de régler le problème, tenté d'ajouter une page à la vue correspondante, tenté de faire le menu à la main, rien à faire. C'est là qu'il m'a refilé le bébé...

La main de la confeature

Souvent quand j'évoque ma manière de travailler avec Drupal, on me rétorque "Ouhlà, tu fais du code custom, c'est pas standard, faut utiliser des modules, sinon comment-ki-font-les-suivants-pour-maintenir". J'étais donc positivement curieux de voir comment un site fait par une société "state of art of drupal" était construit. Et je n'ai pas été déçu du voyage même si je ne sais pas encore bien comment je vais faire celui de retour...

Pour commencer, je me suis pris un usage extensif du module feature. Pour être honnête, j'ai une opinion assez mitigée sur ce générateur de module. Mais utilisé comme cela, je lui confère le titre d'hallucinante usine à gaz au fonctionnement proche de l'enregistreur de macro d'une suite bureautique. En fait features me rappelle le gag du développeur fou à qui on demande de corriger une fonction sensée renvoyer la somme de ses deux arguments. La fonction semble fonctionner, mais lorsqu'on lui donne à manger 1 et 1, elle renvoie 3. Le développeur fou ne tarde pas à trouver la solution en retirant fièrement 1 au résultat final...

Fatures c'est un peu cela. Drupal est in-fichu de proprement gérer un déploiement ? Et bien qu'à cela ne tienne, nous allons créer un générateur de module dans lequel on va injecter du code PHP représentant toute la configuration spécifique pour un site donné (les types de contenu, les champs cck, les vues..). Et comme en standard feature ne connait pas grand chose, on va lui coller features_extra qui va en plus permettre d'y coller les blocs, les menus et la taxo. Et comme un site drupal c'est loin de se limiter à s'y peu, pour le reste, on se démerde à coup de strongarm et du code custom... ah ahhhh !! je ne suis donc pas si seul :-)

Au final on hérite d'une chiée de module qui n'en sont pas vraiment car ils ne s'installent/désinstallent pas normalement, mais uniquement à travers l'interface de features. Ce dernier est alors censé mettre magiquement à jour le site sur lequel les dits modules sont déployés et redéployés. Sauf que c'est un peu de la magie à la Garcimore dès qu'il s'agit de choses un peu complexes comme la suppression d'un champ cck, au hasard...

Entendons nous bien, je suis parfaitement prêt à entendre l'intérêt de feature dans son concept même d'API exportable. Mais en l'état, le fait que ce ne soit qu'un module contribution et pas une api du coeur de drupal fait que sur une installation standard, 80% des paramétrages ne sont pas couvert (en gros dés que l'on sorte de CCK et Views). Du coup l'outil est trop contraignant pour un résultat bien modeste. De plus, lorsque le module généré est, comme pour ce projet, hacké jusqu'à la trogne, on perd tout l'intérêt de la manoeuvre car toute mise à jour de la feature est vouée à l'échec. Il s'agit donc plus de l'usage du module et de son périmètre qui pose problème, que sont idée de dépard.

Ils m'en ont mis plein la view...

En conclusion, les "state-of-art-of-drupal", comme moi, font du code (celui nécessaire pour tout ce que feature ne gère pas). Mais ma réelle découverte, c'est qu'ils font surtout du code pour télécommander des modules... Moi pour faire une liste, je fais une requête SQL, un db_query, un template pour formater le résultat de ma callback, et hop, à Créteil... Eux non. Eux ils utilisent Vieeeewzzzzzz, mais pas comme le pekin lambda, eux ils font du views, dans du code. Des milliers, je dis bien des milliers de ligne de code (4500 pour être exact...) pour paramétrer la génération automatique de vues, de pages associées à ces vues, de feeds, etc, etc, etc... Tout cela innocemment collé dans un hook_default_view_views...

Alors cela "fonctionne" finalement ? En bien pour commencer, nous avons un module pour faire la synchronisation entre le vocabulaire des rubriques/sous-rubriques : taxonomy_menu. Bon, pourquoi pas.

Pour gérer la page "front" et ses 3 articles mis en avant, on ajoute le module nodequeue et l'on fabrique une queue par rubrique. Là, la question est "comment fait-on pour associer une queue et une rubrique". En effet, elle est bonne la question... Car en fait on peut pas. Alors les astucieux ont écrit dans un module custom (encore du code !!) une fonction qui permet d'associer les queues au terme de vocabulaire en passant... par un tableau PHP en dur... Là pour le coup mon pov' client, il ne risquait pas de pouvoir ajouter sa rubrique de si tôt.

Ensuite, parmi les 4500 lignes de génération de vues, s'en trouve un millier dédié à fabriquer les vues/pages/feeds associés avec chaque rubrique en mettant ainsi la vue en relation avec le nodequeue qui va bien, grâce à la fonction PHP magique.

Après encore une grosse poignée de centaines lignes pour générer cette fois les vues des sous-rubriques et on est presque arrivé... Là on se dit qu'on aurait pu en profiter pour associer un menu à chaque page de vue ! Mais non, navigation_menu qui est trop super sympa !

En comme la vie serait triste si l'on n'utilisait pas context, on a rajouté quelques centaines de lignes de code supplémentaire pour générer les contextes associés à chaque rubrique et sous-rubriques...

Résultat des courses, views, nodequeue et context dans une interface graphique à faire fondre les plombs à FireFox (imaginez, une vue, 50 sous-rubriques, 100 onglets tout en ajax ;-). Interface qu'il ne faut absolument pas utiliser puisque tout est généré. Du coup l'intérêt de Views est incertain, mon client ne peux pas les modifiers et le développeur, lui s'empêtre dedans..

Ajouter une rubrique, mode d'emploi...

A ce stade, le client il est sous terre... Car finalement le manuel du "comment ajouter une nouvelle rubrique/sous-rubrique" ressemble à cela :

1. Aller dans la taxonomie pour créer la rubrique et la première sous-rubrique. Taxonomy menu n'a pas fonctionné, le menu n'est pas créé, c'est normal car la page n'existe pas encore... Le lien en lui même (taxonomy/term/xxx) ne fonctionne pas non plus vu que c'est ce type de chemin qui est utilisé par les pages de views et que du coup il y a conflit sur le routeur (c'est certain, il vaut mieux une vue plutôt que thémé simplement la page de taxonomie).
2. Créer un nodequeue...
3. Aller dans le code pour le modifier et ainsi associer ce nodequeue à l'intitulé de la taxonomie (pourquoi pas directement le tid ?)
4. Aller dans views, sur la vue "frontpage", cliquer sur modifier puis la supprimer. Si si, car sinon, Views ne réimporte pas proprement les vues par défaut générées plus haut. Au passage, pleurez un peu car évidemment les vues ont été un peu customisées juste ce qu'il faut pour passer 1/2 heure à les régler à nouveau (opération à refaire à chaque ajout de rubrique, youpi...)
5. Même motif et même punition pour la vue "sous-rubrique"... Mais heureusement j'ai découvert que je pouvais revenir (aka supprimer...) à partir de la liste des vues, donc firefox est sauvé. Ne pas s'étonner qu'à chaque click sur un lien de views ça mette 10 ans à réagir, car l'implémentation du hook responsable de la génération des vues par défaut est appelé à chaque fois...
6. Revenir sur la taxonomie cliquer sur modifier puis directement sauver, et cette fois le menu devrait être créé..

Pour s'en sortir...

Maintenant je ne sais pas trop ce que je vais faire. Je me doute bien que mon client ne sera pas très ravi avec la procédure que je viens d'énoncer. La première étape va donc consister à dégager feature/strongarm pour y voir plus clair. Puis j'imagine que je vais mettre en œuvre un truc un peu plus simple.

• Un type de contenu "Rubrique" avec un titre, un corps et une liste de trois nœuds (nodereference). Le principe sera pour le client de créer un nouveau contenu de type "Rubrique" lorsqu'il en aura une à rajouter. J'associe automatiquement ce contenu au menu de premier niveau et avec un hook_nodeapi je fabrique synchronise le premier niveau de taxo rubrique. En gros 10 lignes de code. Du coup la rubrique étant un nœud associé à mon premier niveau de menu, je gère la "frontpage" par un simple node template. Emballé.
• Pour les sous-rubriques, je laisse le client ajouter ses termes de taxo et je laisse navigation_menu les associer proprement. Du coup la liste des articles est simplement un template sur la liste standard de drupal des articles possedant un terme donné.

Donc en somme, si l'idée fonctionne, une usine à gaz avec 4500 lignes de code Views d'un côté, et un petit module custom disons de 100 lignes, pas de vues, et une pure exploitation des fonctionnalités de base de drupal. Sans aucun doute moins sexy ;-)

Conclusion

Il ne faut pas croire que je sois de mauvais esprit ici. j'ai même un certain respect pour la personne qui a servi de référent technique sur ce projet. Mais cette aventure a été instructive à plus d'un titre. Tout d'abord cela me décomplexe lorsqu'on me dit "Bouh, tu fais du code custom, c'est moins facile à maintenir que des modules". C'est sans aucun doute vrai lorsque le besoin est assez simple pour que les modules utilisés se suffisent à eux-même. Mais pousser la logique modulaire au point de télécommander des modules avec des milliers de lignes de code, c'est aberrant. Aberrant car je suis persuadé que mon équivalent "code simple" est cent fois plus lisible (en tout cas il est 100 fois plus documenté...). Ensuite ces modules ont été pensés pour être utilisés à travers des interfaces graphiques. C'est d'ailleurs souvent dommage car j'aurais préféré, même pour views, que l'API précède l'interface pour que tout le monde soit content. Toujours est il que du coup leur paramétrage ressemble plus à un remplissage de formulaire qu'à l'utilisation d'une API propre. Enfin, purée c'est d'une lenteur tout cela. A chaque click on a l'impression de manipuler un 38 tonnes avec des baquettes de tambour... et chaque "frontpage" de rubrique génère, pour un utilisateur authentifié, pas moins de 786 requêtes SQL !!!!!!!!!!

En conclusion, ce que j'en retire c'est que context est un module qui mérite que l'on s'y penche mais je lui reproche sa dépendance à ctools absolument inutile et proprement rédhibitoire. Feature est une plaisanterie. Drupal a un problème de déploiement indéniable et même grave à l'heure d'un usage professionnel de l'outil. Feature n'est donc qu'un emplâtre sur une jambe de bois. C'est lourd, peu stable, et surtout ne couvre pas toutes les fonctionnalités obligeant à recourir à du code custom. Autant utiliser Backup & Migrate. Views est un très bon outil pour le cadre d'usage "wordpress" de drupal (non péjoratif, car j'aime beaucoup wordpress), permettant à un utilisateur peu ou moyennement expérimenté de construire son site rapidement. Dans le cadre d'un usage professionnel par des développeurs professionnels, l'utilisation de cet outil comme API ne m'a clairement pas convaincu. C'est bordélique au possible et je crains le pire lors des changements de version (en gros views3 implique tout à la poubelle, comme ce fût le cas pour Views1).