Drupal : un CMS ?

De plus en plus de site migrent vers Drupal, j’ai voulu donc voulu voir ce qui poussait les gens à utiliser cet outil. Après plusieurs tests, mon avis à ce sujet est mitigé.

Drupal out-of-the-box ne contient pas grand chose, tout se passent par l’ajout de module. Ce concept me semble dans un premier temps intéressant, mais c’est la que les premiers problèmes commencent. Il faut trouver des composants pour chaque tache.

Les types de données sont limités, on trouve au départ des types pour écrire des articles, des pages et des livres. Ils ne comportent pas grand chose, généralement un champ texte pour le titre, un bloc « riche » pour le contenu, des mot-clés.

Les principaux concepts

Les nœuds

Dans Drupal, tous les contenus sont des nœuds. Il est donc possible d’étendre le modèle de base en utilisant l’identifiant du nœud pour créer son propre modèle de données et d’y attacher des données connexes.

Les taxonomies

Ce sont des ensembles de mots clés pouvant avoir différentes structures (à plat, hiérarchique sous forme de graphe). On peut associer à chaque nœuds un ou plusieurs termes de chaque groupe taxonomique.

Les modules

Les modules sont l’ensemble des codes tierces que l’on inclut dans la logique applicative de Drupal. Ils sont écrits en PHP.

Les blocks

Les blocks sont des petits fragments de html qui sont inséré dans une page Web.

Les thèmes

Ni les nœuds ni les modules ne s’occupent de la présentation, ce sont les thèmes qui s’occupe de la couche de présentation. c’est à dire du rendu HTML / CSS / JS.

Quelques points intéressants

Édition d’un bloc de texte

Par défaut, le bloc « riche » s’écrit directement en mode texte (ce qui n’est pas pour me déplaire). On peut spécifier différents niveaux de filtres sur les balises HTML. L’insertion d’image dans un contenu est plutôt barbare avec une belle balise img et sa src en dur. Passons, de toute façon, le marché actuel du Web impose l’utilisation d’un éditeur WYSIWYG, la communauté Drupal fournit plusieurs intégrations d’outils classique du marché (FckEditor, TinyMCE). Après plusieurs installations de modules et de leurs dépendances, je dispose enfin d’un formulaire d’édition d’un article un peu plus user-friendly commercial. La qualité des intégrations des éditeurs WYSIWYG varie considérablement d’un module à l’autre. Il faut bien faire attention au choix du module.

Type de données

Pour avoir des types de données, un peu plus élaborés, les diverses documentations me renvoient vers le module CCK permettant de définir des champs peu plus spécifiques.
L’installation de ce module ne pose pas de problème particulier, mais la pauvreté fonctionnel de ce module qui n’ajoute qu’une ébauche de virtualisation de données, ne me rassure pas du tout (on est bien loin de ce que propose eZ Publish). Il ne me reste plus qu’une solution c’est de devoir écrire mon propre module pour pouvoir avoir des types de données un minimum structuré.

Les modules

Les modules fonctionnent comme un conteneur IoC. On définit les différents hooks dans le cœur de Drupal pour y injecter notre logique au bon endroit. Les hooks doivent obéir à une convention de nommage, suivant le principe de convention plutôt que configuration. L’idée est bonne, dommage que l’interface proposée n’utilise pas la programmation orientée objet, tout cas sa syntaxe.

Les modules permettent d’enrichir le contenu des nœuds, les hooks fournit permette d’intervenir à tous les niveaux de l’application, que ce soit à la création des nœuds dans l’interface d’admin, la consultation, la suppression, … . Cette partie est plutôt bien faite.

Par contre, l’API fournit par Drupal, bien que fonctionnel, n’est pas des plus riches. La couche de bases de données n’est qu’une encapsulation très simple des fonctions php de base (même pas de PDO), il n’est pas question de mappage relationnel-objet dans cette bibliothèque. Pour les formulaires, l’interface n’est pas des plus intuitives, et correspondent plus à une encapsulation html /js à l’intérieur de fonction PHP.

Modèle MVC

Drupal ne fournit pas d’implémentation d’un modèle MVC. La séparation entre le contrôle et le modèle est inexistante, elle est à la charge du développeur. Par contre, on trouve une séparation stricte entre le contenu et la présentation.

Conclusion

Les idées proposées par Drupal sont très intéressantes, elles s’inspirent des meilleurs pratiques de génie logiciel. Cependant, la non-utilisation de la programmation objet est un manque important à l’outil. Le gros point noir de cet outil est la qualité des modules fournit par la communauté qui est vraiment mauvaise. Sur 3 tests avec des modules différents, je me suis 3 fois avec une base de données où les données sont complètement corrompus. Pour un développement professionnel, on est obligé de systématiquement développer ses propres extensions.

Drupal en tant que CMS n’est pas une solution pour des sites importants, avec des contenus très structurés. Par contre, comme gestionnaire d’article, c’est un outil redoutable qui remplace des outils comme SPIP, Joomla! ou WordPress.

Category: CMS

Étiquettes :

- 5 mai 2009

Comments

  1. Je suis étonné par cet article, les retours que j’avais pu avoir sur Drupal était une communauté proposant des modules de qualités justement et permettant d’enrichir fortement l’outil.

    Il va falloir que je teste par moi même pour voir vraiment comment il fonctionne 🙂

    Très bon article en tout cas !

  2. C’est aussi l’impression que j’avais avant que je commence à l’utiliser, ma déception fut grande.

  3. J’ai poussé un peu le produit, je suis d’accord que le marché veut du Drupal, mais il n’empêche que l’outils est quand même minimaliste, à part le principe du conteneur IoC y a pas grand chose.

  4. T’as des actions chez Drupal ? Franchement, Drupal c’est un bon produit en remplaçement de Joomla! ou Spip, mais après tu as besoin d’une coquilles vide tu part sur du Zend ou Symfony, tu as besoin d’une boutique Magento, tu as besoin d’un CMS pro tu part sur de l’eZ Publish. Drupal est plutot bon partout mais dans tous les domaines, il y a un outils qui est meilleur, c’est simplement ça son problème.

  5. Salut Sylvain,
    Dans la boite où je travaille, nous faisons des sites pro, avec des contenus éditoriaux, des sso (open id), des gestions de cookies avancé, de l’accessibilité quand le client le demande (oui oui ^^), multilingue, workflow de validation avancé, boutique avec Ubercart, modules communautaire… etc… etc…
    Avec le multi rendu, nous avons meme fait un site flash contribué avec drupal, qui a une version html pour etre mieux référencé (merci swfobject et les XML).
    Je ne sais pas quels modules tu as pu tester, néanmoins, soit vigilant à la notion de « release ».
    Si tes clients ne sont pas convaincus par le professionnalisme du produit, tu peux toujours prendre la version d’acquia qui contient plusieurs modules testés, éprouvés, par défaut. S’il est toujours sceptique, il existe un abonnement entreprise, avec support 24h/24h.

  6. Je pars du principe qu’il vaut mieux une coquille vide a laquelle tu peux ajouter ce que tu veux, qu’un outil rigide, qui embarque beaucoup de fonctionnalités (comme c’est le cas des outils embarquant beaucoup de fonctionnalités). La question est : que veux tu faire de ton site ?
    C’est un fait que pour une pure boutique en ligne, il vaut mieux passer sur un Magento par exemple (en plus c’est MVC 😉 ), pour un site pur métier, peut être passer en framework zend ou symfony… En revanche, quand tu t’embarques dans un dev boutique ou métier, il y a aussi des contraintes non ? Si je veux créer un blog a coté, si je veux faire une rubrique « actualités »…
    Avec drupal, les gens ayant tous des besoins différents, tu peux adapter tes fonctionnalités, ton hébergement, l’orientation de ton site, et utiliser les modules (voire créer les tiens).
    Le marché ne « veut » pas du drupal. On ne choisi pas un outil par phénomène de mode (enfin pas moi en tous cas). C’est après un benchmark assez long que nous en avons conclu que c’était l’outil le plus robuste, qui permettait le plus de polyvalence et de propreté de code.
    De plus, la communauté répond présent un peu partout dans le monde, ce qui promet à l’outil encore quelques années devant lui.
    Encore une fois si tu veux une coquille pleine, teste la vers drupal aqcuia.

  7. Très loin de moi l’idée de trouver EZPublish comme étant une mauvais produit. Je ne rentrerais tout simplement pas dans le débat manichéen de « qui est le meilleur ». Cependant, quand je lis en gras dans une conclusion, que pour un développement professionnel, on est obligé de systématiquement développer ses propres extensions, je dis que ce n’est pas vrai.

  8. Allez je me lance,

    J’ai fait plusieurs sites sous eZ, sous Drupal, et quelques projets sous Symfony, donc je dirai qu’au niveau de la taille de la bite, ben ça dépend du point de vue. De mon point de vue ils ont chacuns des intérêts et des inconvénients.

    Concernant Drupal, oui c’est une coquille vide, un IoC avec une implémentation orienté fonction, qui amène juste quelques notion de base et des hook sur le cycle de vie de tous les aspects du sites.
    De base : Noeud, Menu, Block, Theme that’s it. Impossible de faire un site avec un drupal vierge, pas de WYSIWYG, pas de gestion de média. Par contre il y a foisons de modules tout à fait bluffant, parfois pour faire pas grand chose, parfois des trucs incroyable.

    La grande qualité technique de Drupal pour moi c’est la facilité pour étendre les fonctionnalités et de les mutualiser. Rajouter une fonctionnalité, une api, un écran d’administration, étendre la base de donnée est très simple. Ce qui permet de répondre à de nombreuses demande spécifique assez facilement.

    Au final tes conclusions sont en partie juste, Drupal est un empty shell, un IoC, pas OO, certains modules sont + ou – douteux, pas de vraie implémentation MVC. Par contre la conclusion sur les développements spécifique IMHO valable pour tout CMS pour autant que le projet soit conséquents.

    Enfin je pense que tu te trompe quand tu dis que pour chaque problème il y a un outil qui surpasse Drupal. On peut considérer ton affirmation est toujours vraie, dès que tu essais de faire plusieurs choses dans un seul outil il y a forcément un axe plus faible. Magento c’est son Back Office lent et ses capacités CMS limités, Symfony/Zend ca sera le temps de conception / réalisation supplémentaire pour réaliser une fonctionnalité out-of-the-box d’un autre outil, eZPublish ça sera son templating (sic), ses Workflows, sa boutique.

    Je pense donc pour toutes ses raisons qu’il y a un espace pour Drupal. Un outil avec des qualités certaines.

    cheers

    A quand un drupal like s’appuyant sur Zend ?

  9. A quand un drupal like s’appuyant sur Zend ?

    Bientôt, si je trouve du temps et quelques gens motivés pour m’accompagner …

  10. Ha tu vois, Finalement Drupal sbien! tu veux même le porter sous ZF! ^_^

  11. Salut à tous,

    Hum, je tombe sur ce sujet, un peu par hasard, et je tombe de haut en lisant cet article…

    Je le dit haut et fort, l’auteur de l’article n’a visiblement aucune idée de ce qu’est Drupal.

    Cet outil est un mélange entre un CMS ET un Framework.

    Sa conception « core_system » est optimisée, sécurisée, performante à souhait (plus de 10 ans de maturité sur le projet …).

    Les modules et les contributions, même en version gratuite (c’est à dire sans support pro) sont surveillés, à la fois par la communauté qui les utilise fréquemment, tout autant que par une équipe spécialisée qui veille particulièrement à ce que chaque module Drupal soumis réponde au Cahier des Charges des modules Drupal (sécurité, stabilité, modularité, norme du code et des commentaires etc.) sans quoi la contribution ne peut pas être proposée.

    Entendre que Drupal n’est pas une solution pour les professionnels, revient à dire que les professionnels qualifiés de chez Microsoft, IBM, L’Oréal, LA NASA, La Maison Blanche, Universal, et de centaines autres références internationales sont des incompétents finis pour avoir choisis Drupal (en interne comme en prestation de services …).

    Drupal Version 6.x ne propose pas beaucoup de fonctionnalités en natif, car tout est orienté autour des modules.
    Il n’existe nulle part ailleurs des modules tels que CCK et Views (vitrine de la puissance de Drupal et pour ne citer qu’eux sur les huit mille existants…).
    Ne même pas connaître ces modules et pondre un article sur Drupal est tout bonnement inconcevable.
    Quand on ne connait pas un sujet, l’abstention est de rigueur.

    Sur les critiques qui sont faîtes, la nouvelle version de Drupal (Drupal 7.0) a été réalisée en OO. Si cela n’avait pas été fait avant, c’était pour un soucis de performance ainsi que de « cloisonnement », car les modules Drupal communiquent entre eux (encore l’un des point fort Drupal) et à l’époque la conception Objet de PHP n’était pas suffisamment avancée.
    L’évolution des librairies PHP et de sa conception Objet (non prévue à la base) permettent à présent à Drupal d’exploiter ce potentiel.

    Concernant les perf, Drupal possède le meilleur système de mise en cache éprouvé à l’heure actuelle.

    S’il faut faire des critiques autour de Drupal, ce n’est surement pas sur sa conception.

    C’est un outils pro, difficile et long à prendre en main, mais la plus-value que représente sa maîtrise n’est pas négligeable.

    Enfin, pour finir, je n’ai pas d’action chez Drupal, mais je suis l’un des nombreux prestataires professionnel qui vis de cet outils et des réalisations que l’on met en place avec.

    La demande CLIENT en matière de Drupal augmente en France, mais les compétences ne suivent pas.

    J’envoie l’avis suivant, à qui veut bien l’entendre, qu’il y’a du travail très bien payé et de la place pour les développeurs et professionnels Drupal à l’heure actuelle, en France notamment.

    Il faudra compter sur Drupal pour les années à venir et les prochains gros projets Web.

    Merci de ne plus poster d’articles aussi catégoriques alors qu’aucun travaille de fond n’a été effectué sur le sujet.

    Bien cordialement.

  12. Cet article est un peu vieux mais il n’en reste pour le moins exact sur de nombreux points. Connaitre les défauts de Drupal n’est pas une mauvaise chose et je le pousse régulièrement cette solution sur des projets. Drupal 7 corrige de nombreux points que je soulevais donc je ne pense pas que j’était loin de la réalité à l’époque.

    Il faut également remettre cette article dans son contexte, à une époque où Drupal était la solution universelle que tout le monde pouvait mettre en place en 5 minutes. Le raté du site france.fr a fait beaucoup de bruit parce que Drupal était mal utilisée, mais c’est loin d’être le seul site dans ce cas. Mainteneur de site Drupal est devenu un vrai métier, une vrai spécialité, l’année dernière parce que comme tu le dit Drupal nécessite un apprentissage qui est long et des connaissances de l’environnement de production qui ne sont pas à la portée de tout le monde tu en ai la preuve vivante.

    Drupal 7 a fait de gros efforts et apporte de réelle solution à certains manquement que je mentionnais ici.

    CCK existe dans de nombreux autres produits qui n’ont pas la popularité de Drupal : le plus pro est sans doute eZ Publish qui possède un système de ce genre depuis ses origines.

    CCK est complètement refondu et intégré au core dans la version 7, mais l’approche dans la nouvelle version est complètement différente. L’interface graphique n’est plus la porte d’entrée c’est la conséquence alors que c’était le cas dans CCK. Le passage entre les différentes versions d’un même projet était juste horrible et non versionnable.

    Views est une hérésie, en tout cas l’utilisation qui en fait, c’est peut être pour cela qu’il n’a pas été intégré dans le coeur de l’application de la version 7.

    Sur la POO, on ne peut toujours pas parler de véritable POO dans Drupal, ce n’est pas problématique mais c’est un fait.

    Faire les modules à la main n’est pas forcément une mauvaise chose loin de là, c’était plutôt un avantage.

    Sur les module existant, il y a beaucoup de modules qui ne devrait pas être la. C’est surtout la combinaison de certains modules qui posent d’énormes problèmes. Oui, un module qui fait 800 requêtes par page ne posent pas de problème sur un ordinateur en local mais sur des montées en charge c’est beaucoup plus complexe. Le cache est une solution mais elle n’est pas applicable sur toute les pages mais est tu prêt a mettre 10 Go de données en cache qui se vident tous les jours parce les données on changé ? Donc View, Panel et autres modules du même genre sont à utiliser avec parcimonie.

    Sur le système de cache, il a du cache natif qui n’est pas suffisant car il faut nécessairement avoir un cache de plus haut-niveau (serveur memcached, …). Ce n’est d’ailleurs pas le rôle d’un CMS de gérer complètement le cache.

    « Merci de ne plus poster d’articles aussi catégoriques alors qu’aucun travaille de fond n’a été effectué sur le sujet. »

    « Quand on ne connait pas un sujet, l’abstention est de rigueur. »

    Cette article a été écrit après avoir utilisé Drupal sur des projets divers pendant 2 ans, avoir discuté avec des développeurs / chefs de projets / chefs d’entreprises / admin sys / utilisateurs finaux / webmasters qui utilisent ou ont utilisées Drupal sur des sites alors maintenant écoute moi bien Dorian , tu est jeune, tu est étudiant en licence pro Licence Pro Communication et Médias c’est bien mais as tu déjà développé, mis en production et maintenue un site sous Drupal ou même un site tout simple ?

    Admettons que je n’avais aucune idée de ce qu’était Drupal à l’époque mais ce que je peut dire aujourd’hui, ce que toi non plus tu n’a pas non plus une vision d’ensemble de Drupal, de PHP et du Web en général.

    Avec Drupal 7, seule ma conclusion change, maintenant il est possible de le mettre sur des sites avec des contenus très structurés.

  13. Ha, tu t’es fait un ami.

    Encore un jeune qui vient de lire un livre ou voir une conf sur Drupal. Il croit que c’est la solution miracle sans avoir tester les autres produits.

    Balancer le nombre d’extensions et les références c’est à la mode mais c’est la même chose pour tous les CMS et les frameworks.

  14. Bonjour,

    Je vous prie d’abord de m’excuser pour le ton que j’ai utilisé, car ce n’est jamais approprié de réagir de la sorte.
    Mea culpa.

    Richard, pour vous répondre, je ne réagis pas après avoir lu un livre ou assisté à une conférence.
    Je gagne ma vie, presque exclusivement, grâce à Drupal.

    Donc oui, j’ai une expertise Drupal éprouvée et ais mis des sites Drupal en place. J’interviens en MOA, formation et développement sur des projets Drupal.

    Et je ne suis pas en licence pro mais issus du cursus de l’Epitech.

    J’espère pouvoir faire une remise à zéro des compteurs (aussi bien pour ton article, Sylvain, que pour mes commentaires) et vous invite à ouvrir une discussion construite autour du sujet.

    Je serais intéressé d’avoir vos retours d’expériences (qui vous amènes à des conclusions si catégoriques) et de vous exposer les miens.

    Bien cordialement.

  15. C’est dommage qu’à l’epitech ils vous apprennent pas à rester humble.

    En tout cas, ca ressemble quand même beaucoup à une licence pro :
    http://forum.lpcm-cergy.fr/archive/index.php/thread-12.html

Laisser un commentaire

Your email address will not be published / Required fields are marked *