Un avis de la communauté ?

Hello,

C'est simple, pour un "développeur hard core" qui attache de l'importance à l'élégance structurelle et qui aime contrôler les choses de bout en bout, Drupal ne convient pas (ni PHP à ce compte là) : ce que tu recherches, c'est un "vrai" framework, ce que Drupal n'est pas donc il ne trouvera pas grâce à tes yeux.

La cible que vise Drupal, ce sont ceux qui recherchent un outil à mi-chemin entre CMS et framework : CMS dans le sens où on obtient un résultat "prédéfini" rapidement, framework dans le sens où il est possible de réaliser presque tout type de site et qu'il est assez flexible pour être personnalisé dans la plupart de ses aspects, en "empilant" des modules ou en créant les siens. On est d'accord qu'il ne sera pas aussi flexible qu'un CakePHP ou un Django, mais c'est suffisant pour beaucoup de monde. Exemple : les "distributions" Drupal comme OpenAtrium ou Drupal Commons fournissent des installations de Drupal + modules préconfigurés pour répondre à un besoin précis, et ce en utilisant l'API de Drupal. C'est quand même plus souple qu'un CMS classique.

Pour répondre point par point :

1) Approche procédurale

Ton soucis principal est que ça restreint la modularité car ce n'est pas aussi souple que travailler avec le modèle objet. Cependant en utilisant Drupal on se rend compte que dans presque tous les cas il offre une modularité suffisante. Pour des raisons historiques Drupal n'a pas pu être conçu en orienté objet, et aujourd'hui une réécriture complète est impossible. Par contre, Drupal n'est pas en général un exemple de mauvais code PHP, et utilise de plus en plus les concepts objets quand il en a besoin.

2) Modularité discutable

Après de nombreux sites plus ou moins nombreux avec Drupal, j'ai rarement rencontré des conflits entre modules. De même, choisir le "meilleur" est facilité puisqu'on a accès à des informations du genre dernière release, stable ou pas, dernier commit, nombre de mainteneurs, nombre d'utilisateurs, nombre de téléchargements, et tous les commentaires, bugs et demandes. De plus depuis Drupal 6 les modules sont plus surveillés pour éviter les doublons de fonctionnalités.

Pour les patchs, je ne suis pas sûr de ce que tu veux dire, mais justement la règle est d'éviter les patchs, surtout du cœur de Drupal, et sauf cas particulier ce n'est pas autorisé.

Pour le mécanisme de hooks je suis assez d'accord, il faut faire avec.

3) Emploi de la base de données

Là on est d'accord, trop de choses sont en bases de données, notamment la configuration. De plus en base la configuration n'est pas clairement séparée du contenu, ce qui complique la gestion des versions et des mises en production. Cela dit, n'oublions pas que l'édition du contenu ne se fait qu'en environnement de production.

Comme c'est un problème qui apparaît systématiquement lors de l'utilisation "industrielle" de Drupal, il y a des initiatives pour pallier à cette déficience, dont la plus populaire est le module Features qui doit permettre d'exporter une "fonctionnalité" (sous-ensemble de la configuration d'un site, par exemple une galerie d'images) pour l'appliquer sur un autre environnement. Le but est précisément de régler le workflow entre des environnement dev, staging, prod, etc, de pouvoir l'intégrer dans le code et donc dans un gestionnaire de versions, et de pouvoir revenir en arrière à n'importe quel moment.

Conclusion ?

Conclusion, c'est selon les exigences du projet qu'un framework ou un CMS seront plus adaptés, mais il serait dommage de ne pas utiliser de CMS lorsque cela est possible. Si je suis ton raisonnement, une fois réglé le problème de gestion d'environnements il n'y aura plus grand chose à reprocher à Drupal à part si l'on ne souhaite travailler qu'en orienté objet ^^

Salut Gauthier,

J'ai lu ton échange avec mdupont et ton billet original et ses commentaires ("Pourquoi je déteste Drupal") avec beaucoup de plaisir.

Je m'étonne que le présent fil de discussion n'ait pas généré plus de réactions. Le titre trop vague (tentative de teasing ?) et la date de publication bien estivale y sont sûrement pour quelque chose.

Personnellement, ça fait cinq ans que je bosse avec Drupal et qu'il me fait vivre via des prestations de développement et de formation. Je suis donc "aux premières loges" pour constater les limites de Drupal que tu évoques dans ton billet. Cela dit, on sent dans ta prose le gars "confronté à Drupal lors de missions chez différents clients" (le gars un peu forcé, qui n'a pas forcément des années de projet Drupal derrière lui). Je comprends que si t'aimes pas, tu vas pas t'attarder, mais j'aurais aimé un article plus factuel, avec des exemples plus concrets, peut-être en comparant comment d'autres CMS ou frameworks gèrent des problématiques équivalentes.

Des phrases comme "la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6..." ou "cette vilaine manie qu'ont les développeurs de recourir aux patches", ça sent la généralisation abusive. Je passe sur l' "approche procédurale" et l' "emploi déraisonnable de la base de données", car ce ne sont pas des arguments, ce sont des faits, et il n'y a pas à en débattre (cela explique peut-être le manque de réaction des "représentants officiels").

Moi, ce qui m'aurait bien plu, c'est que tu nous parles de ce que tu kiffes, que tu nous proposes d'autres pistes. OK, t'aimes pas Drupal et les "vrais" frameworks c'est canon. J'aimerais en savoir plus.

Il se trouve qu'en ce moment, j'apprends Python et Django (vais-je bientôt haïr Drupal moi aussi ?). C'est un vrai régal. D'abord parce que Python a une concision et une expressivité que PHP n'a pas. Python est "Pythonique", comme ils disent là-bas. Ensuite, parce que Django donne l'impression de retrouver la liberté : exit les nodes, bye bye CCK et Views, plus de galère pour gérer le contrôle d'accès...

Cela dit, un truc me turlupine... les sites web que je vais créer avec Django auront besoin d'un système de tags, de types de contenus maison, de profils utilisateur, de redimensionnement automatique d'images, de votes, de commentaires, de formulaires Ajax... Classique, quoi.

Pour toutes ces choses, Drupal me propose une solution (ie. un module). Plus que des modules, Drupal me propose des choix d'implémentation. Je m'explique : c'est comme s'il y avait une façon Drupal de faire les choses (il y a les noeuds, la taxonomie, les hooks, les fonctions de thème, etc.). Même si ce Drupal way of life est parfois une énorme contrainte, c'est aussi très reposant (et un vrai time-saver) pour un développeur qui n'a pas à faire ces choix lui-même.

Avec Django, j'ai perdu ce cadre. Il existe bien sûr (il y a les modèles, les templates, les vues...), mais il est de beaucoup plus bas niveau. En tant que développeur, il me laisse la responsabilité de nombreux choix à faire.

Je prends un exemple (simplifié) : Drupal m'impose une façon de gérer mes templates, il me dit où les mettre et comment les nommer, et en contrepartie il me garantit qu'il les utilisera au bon moment. Dans Django, je peux mettre mes templates où je veux, leur donner le nom qui me chante, et les appeler uniquement les soirs de pleine lune. Pas de convention, pas d'obligation. Opportunité certes, mais aussi "malédiction". Ai-je envie de prendre toutes ces décisions moi-même ? Ai-je le temps ? Ne risqué-je pas de me tromper ?

Alors, ça va te paraître dingue, mais j'ai tendance à reproduire le fonctionnement de Drupal avec Django. Un peu comme le gars qui une fois sorti de prison continue à vivre dans 9m2 parce qu'il ne sait plus faire autrement. :-)

Bien-sûr, c'est mon manque de pratique du framework qui parle. Avec le temps et l'expérience, je m'affranchirai sûrement de cette Drupalisation systématique. Mais après un petit mois d'incursion en territoire Django, je découvre déjà que la communauté affronte des problématiques pas radicalement différentes de celles qu'on trouve chez Drupal.

Deux exemples rapides :

• Django n'a pas d'outil de migration de schéma (cf. le pb de workflow prod-preprod évoqué dans ton post) ; plusieurs "solutions" existent, une semble s'imposer (South) mais elle ne fait pas partie du framework. Comment gérer la chose ?

• Django peut être étendu via des "applications" (plus ou moins l'équivalent des modules Drupal) mais aucune convention ne gère la façon dont ces applications doivent communiquer entre elles ou déclarer leurs settings au projet principal (cf. la modularité très discutable évoqué dans ton post). Comment gérer la chose ?

Je ne connais pas Symfony ou Zend Framework, mais j'imagine qu'eux aussi ont leurs zones d'ombre.

Si tu as un framework qui sort du lot à recommander, je suis preneur. J'ai envie de m'améliorer, pas de défendre Drupal aveuglément.

Enfin, si tant est qu'il soit nécessaire de le préciser, tu auras compris que j'ai moi aussi écrit ma réponse dans l'esprit d'une discussion constructive. :)

Pour ma part je ne suis pas trop d'accord sur le cote mauvaise qualite d'un site drupal facon Ikea. L'avantage de la solution drupal est que normalement une tres grande partie du code existe et est maintenue par d'autres personnes (sur d.o). Ceci permet donc en theorie de ne pas avoir a ecrire enormement de code et donc lorsqu'on arrive sur un projet fait avec Drupal il ne devrait pas trop trop y avoir de surprises.

Je sais tout a fait qu'il est possible de faire des choses terrifiantes (hack du core, php dans les templates et php ds la bdd via des "computed field" par exemple) mais normalement a grand coups de diff on peut retrouver relativement vite ses mouton (sauf cas explicite par Yoran sur un site avec une centaine de views :D ).
Du coup un site Drupal doit pouvoir passer d'une equipe a une autre "relativement" aisement. Si on compare ca a un site fait en php, django ou que sais-je ou tout est possible, je pense que la transition est bcp plus difficile surtout si l'equipe passee a fait des choix architecturaux douteux.

Ceci dit personnelement je me heurte a la complexite de faire vouloir faire des trucs a Drupal pour lesquels il n'est peut etre pas fait pour ou dont je n'ai pas suffisamment de connaissances... Par exemple, je travaille sur un intranet pas necessairement complexe mais ayant beaucoup de relations entre les nodes et d'implications sur les droits d'acces/edition de ces derniers. Du coup je suis oblige d'ecrire beaucoup de code pour faire en sorte que tout se mette a jour ensemble qd une modification est faite sur un node. C'est plutot laborieux. Cependant, je ne me mettrai pour rien au monde a developper des modules aussi complexes que date/calendar si je devais tout faire de maniere custom.

Pour le moment je travaille principalement en Oracle Forms/Reports et la rapidite avec laquelle nous pouvons sortir des ecrans de capture et de reporting me donne envie de trouver un outil web avec des capacites similaires tout en disposant d'un nb et d'une variete de modules telle que l'a Drupal. Mais bon, je cherche toujours ;)