De mon point de vue, l’une des grandes forces de Drupal est sa modularité. Je développe sous WordPress depuis bientôt 5 ans, et presque 30% des sites réalisés n’utilisent pas les articles de WordPress, mais uniquement les pages. Et je ne vous parle même pas du pourcentage de projets n’utilisant pas les commentaires…
Malheureusement, WordPress ne permet pas la désactivation des fonctionnalités non utilisées, c’est regrettable à plusieurs points. Le premier, c’est les performances, charger en mémoire des lignes de code non utilisé peut s’apparenter à un gâchis de ressources. Le deuxième point, c’est la présence de menus inutiles dans la console d’administration. Cet aspect peut être corrigé via des plugins permettant la personnalisation la console d’administration, ces derniers proposent de choisir précisément les fonctionnalités que l’on souhaite afficher ou masquer.
Mais revenons à drupal…
Lorsque je discute avec des clients, des développeurs, on me dit, WordPress ce n’est pas vraiment un CMS, Drupal oui !
C’est vrai et faux, en fait techniquement parlant, ces 2 outils sont des CMS. WordPress est un CMS orienté gestion de contenu personnelle (plutôt blog), tandis que Drupal est un CMS « non orienté ». Autrement dit, Drupal est extrêmement générique et on le ressent bien à l’installation. (Comme l’on dit plusieurs blogueurs de la communauté WP, WordPress est beaucoup plus packagé que Drupal, plus « ready to use »).
Cette orientation, publication personnelle/blog, est donc à la fois la plus grande force et faiblesse de WordPress.
Force, car cela lui attire la sympathie d’un très grand nombre de webmestres, développeurs et surtout des utilisateurs. Faiblesse, car comme beaucoup d’outils de masse, on le considère à tort comme un outil d’entrée de gamme peu adapté au monde professionnel et à un usage CMS. Et pourtant…
J’ai installé un drupal en local, et j’ai comparé les modules par défaut de drupal avec ceux de WordPress. Vous trouverez dans un premier le tableau comparatif, puis mon analyse.
| Module drupal | Alternative WordPress | Commentaire |
|---|---|---|
| Aggregator | Plugin : WP-o-matic | Ancien, mais plugin très complet |
| Blog | Natif | - |
| Blog API | Natif | - |
| Book | Natif + Plugins | Les pages de WordPress non ? Couplé à un plugin Séries ou une navigation bien pensée ;) |
| Color | Natif + Thèmes | Dans WordPress, le thème peut avoir une page d’administration. C’est le cas du thème par défaut, il permet à l’utilisateur de modifier le schéma de couleur de certains thèmes. |
| Comment | Natif | Permets aux utilisateurs de commenter et de discuter le contenu publié. |
| Contact | Plugins : Cforms | Cforms, what else ? |
| Content translation |
Plugins | Qtranslate, WP-ML, il y a pour tous les goûts… |
| Database logging | Plugins | Partiel, pas de plugin générique à ce niveau. |
| Forum | Plugins ou bbPress | bbPress se couple facilement à WordPress. La prochaine version devrait être encore plus intégrée à WordPress ! |
| Help | Natif | Pas besoin d’aide pour utiliser WordPress ! ;) |
| Locale | Natif | - |
| Menu | Plugins | Par défaut, pas grand chose. (ça devrait changer dans WP 3.0), mais des plugins permettent cela |
| OpenID | Plugins | - |
| Path | Natif | Par défaut, les permaliens… |
| PHP filter | Plugins | - |
| Ping | Natif | - |
| Poll | Plugin : WP-Polls | - |
| Profile | Plugin : BuddyPress | Des profils, mais pas seulement… |
| Search | Natif | Sans compter les innombrables plugins à ce sujet |
| Statistics | Plugins : Wassup, StatsPress | - |
| Syslog | Plugins | Des plugins permettent des logs pour l’activité, d’autres pour le développement. Globalement ca existe. |
| Taxonomy | Natif + Plugins | L’API le supporte, les plugins apportent la couche utilisateur. |
| Throttle | Pas vraiment | À ma connaissance, aucun plugin ne permet de désactiver des fonctionnalités selon la charge. Cependant, les plugins de cache permettent ponctuellement d’alléger la charge serveur. Conclusion, pas vraiment ! mais pas très utile ! |
| Tracker | Natif + Plugins | Les commentaires sont des contributions utilisateurs, sinon des plugins comme TDO Form permettent de créer des formulaires publics. |
| Trigger | Natif | Similaire aux actions/filtres de WordPresss |
| Update status | Natif | - |
| Upload | Natif | Depuis bien longtemps + La retouche d’image depuis WordPress 2.9 |
Comme vous pouvez le constater, mis à part 1-2 fonctionnalités mineures qui n’ont pas d’alternative complète sous WordPress, la totalité des fonctionnalités des modules intégrés dans Drupal possède une alternative ou plusieurs alternatives. Parfois nativement, parfois sous la forme de plugins de la communauté !
Lorsque la fonctionnalité est native, elle possède le même niveau de qualité que sa concurrente drupal. Lorsqu’il s’agit d’un plugin, c’est variable. Certains plugins de la communauté sont bien plus évolués que leurs concurrents par défaut de drupal (mais des plugins drupal peuvent équilibrer la balance), tandis que dans certains cas, c’est l’inverse.
Je conclurai en 3 points.
1. WordPress n’a rien à envier aux modules de base de Drupal. La communauté très active remplit parfaitement son rôle en réalisant des plugins de qualité similaire.
2. Le programme de plugins « officiel » de WordPress.org va permettre de constituer une base de plugins sûrs, vérifiés et mis à jour régulièrement. Ces plugins deviendront l’équivalent des modules de drupal.
3. Drupal possède une longueur d’avance concernant la possibilité de créer nativement des types de contenus à la volée. (je ne parle pas de CCK, mais des types de contenus), WordPress supporte depuis très longtemps ce genre d’ajout via des plugins, mais rien de très propre. La version 3.0 ajoutera une API complète permettant d’ajouter autant de types de contenu que souhaité.
Dans un prochain article, je vous parlerai de Views/CCK et WordPress !
PS: J’ai sûrement oublié certaines fonctionnalités, je pense par exemple aux permissions, je me suis contenté des modules de base pour le moment, mais si vous voyez des fonctionnalités de bases qui n’existe pas dans WordPress, dites-le-moi, j’essaierai de trouver l’alternative si elle existe !
Bonsoir, merci pour cette comparaison, mais je ne suis pas d’accord avec toi pour beaucoup de choses… et si j’ai décidé de faire le passage de WordPress à Drupal pour certains sites, c’est justement parce que dans le core + modules de base, je ne trouvais pas ce qui me fallait.
Non, Book n’est pas l’équivalent des pages, et Organize Series ne complète pas assez Books (qui permet par exemple d’imprimer d’un seul coup le contenu du livre, chose impossible avec Series, ou avec les pages).
Non, Color n’est pas l’équivalent de ce qui existe dans certains thèmes de WordPress. Parce que justement ce n’est pas une fonctionnalité de thème, mais une fonctionnalité « pour faire » des thèmes. Autrement dit l’outil, et pas le résultat.
Non, contact n’est pas l’équivalent de CForms. C’est beaucoup plus simpliste ^^ (mais c’est natif). En revanche, il existe aussi des modules comme CForms :) (donc sur ce point je capillotracte).
Non, WPML ou Qtranslate n’apportent absolument pas les fonctionnalités d’i18n. C’est d’ailleurs ce module qui m’a fait passer à WordPress. J’ai fait deux articles sur la traduction dans WordPress, avec les limites des principales solutions.
Et honnêtement, pour l’instant, on bute très fortement sur le modèle de données WordPress. Tant que celui ci n’aura pas évolué (il parait que c’est dans l’air mais pour plus tard), on ne pourra pas avoir la puissance et la complétude d’ i18n dans WordPress.
Pas besoin d’aide pour utiliser WordPress ? Euh, …. et pourquoi il y a un forum de support alors ? ;) Mais en revanche oui, WP est nettement plus simple. Ne pas oublier pourtant que ce module permet aussi de créer une aide pour les utilisateurs finaux. (Comme par exemple, dans le monde WordPress, comment je fait pour mettre un article en tête de ma page magazine ?)
Oui, les permaliens sont natifs dans WordPress et pas dans Drupal. En revanche, les possibilités de Path dépassent très très largement celles des permaliens WP.
PHP filter (et HTML filters) c’est plus que la simple possibilité d’utiliser du PHP dans un article, c’est la possibilité de décider quels sont les utilisateurs, et les types de contenu (y compris CCK) pour lesquels on va appliquer tel ou tel filtre.
Non, la taxonomie de WordPress telle qu’elle est implantée n’est pas l’équivalent de la taxonomie de Drupal. D’abord justement parce que pour l’instant il n’y a pas d’interface visuelle pour définir en trois clics de souris des taxonomies alternatives, même si la structure de la base de données le permet. Ensuite, parce qu’il n’y a pas non plus la possibilité de définir pour chaque taxonomie, chaque terme, quel est son type (obligatoire, valeur unique, valeurs multiples, restreint à liste ou pas).
Ensuite, parce que les taxonomies WordPress, à l’exception des catégories ne sont pas prises en compte par les plugins de traduction.
Enfin, parce que sauf programmation « directe », il est impossible d’intégrer facilement une taxonomie supplémentaire, soit dans wp_query, soit (cf. plus haut) dans la structure de permaliens.
Throttle n’est effectivement sans doute pas nécessaire sur les sites WP. Quoique…. mais bon, là il s’agit plutôt de problématiques de très gros sites.
Non, Trigger n’est pas similaire aux actions / filtres de WP, tout simplement parce qu’il peut s’utiliser dans l’interface d’admin, sans programmation. Et je ne connais sans doute pas assez, mais je ne suis pas sure qu’on puisse facilement faire « avertir tel groupe de user quand tel type de contenu a été posté ». (Facilement étant le mot clé).
Oui la gestion des images est largement supérieure chez WordPress.
Et ce que tu mentionnes en passant, la gestion fine des autorisations, par type de contenu, par type d’utilisateur, etc… change encore énormément de choses. C’est à la fois un plus et un moins par rapport à WordPress, un plus de fonctionnalités, un moins parce que beaucoup de paramétrages.
Mais pour te donner un exemple, je peux avec CCK (qui sera je crois dans le core de Drupal 7, et qui est beaucoup plus que nos champs personnalisés), définir un champ contenant l’url d’un fichier, et restreindre l’accès à ce fichier à un groupe d’utilisateurs, tandis que tous les autres peuvent voir la totalité de l’article, sauf ce champs.
Alors « qualité similaire », oui à 100%
« Contenu et fonctionnalité » similaires ? Non. Je suis un wordpressienne convaincue, mais j’ai l’impression que dire cela, c’est comme comparer une peugeot à un bus pullman. Oui, les deux me permettent de rouler d’un point à un autre, en transportant des bagages, mais bon… la méthode et les possibilités sont quand même sérieusement différentes. Dans certains cas on a besoin du bus, et dans d’autre de la voiture :)
Je pense que c’est complètement idiot de réléguer WordPress à un « outil de blog », et il peut faire largement plus. Mais il peut quand même moins que Drupal (ou plus, pour les images)
Merci pour ce petit comparatif. Je me pose la question en ce moment car je cherche des fonctionnalités non existantes sur wordpress. A moins que je passe à modx …
ayant développé quelques sites réellement CMS pour des utilisateurs novices en matière informatique et en matière de publication de contenu, j’ai privilégié WordPress pour sa très grande facilité d’emploi (souvent couplé à WLW en tant qu’outil de mise à jour).
Je rejoins cependant totalement Marie-Aude sur ses observations concernant le modèle de données de WordPress : il s’agit là de l’un de ses principaux points faibles.
On peut également y ajouter le fait qu’une extension soit nécessaire pour rendre un site multilingue, alors que cela pourrait être une fonctionnalité native de WordPress.
En dehors de ces deux critiques fondamentales je n’ai pas grand chose à redire concernant cette plateforme efficace, simple et performante…. et mes clients … encore moins !
Merci pour la comparaison ! J’utilise à la fois wordpress et drupal et cette comparaison est proche du parfait (jamais rien n’est parfait ;-) ).
Globalement, je dirais que le comparatif montre que les 2 sont équivalents out-of-the-box mais dans la vraie vie, personne n’utilise Drupal tel quel, au contraire de WP.
Drupal est complété par CCK+Views(+Workflow), qui n’ont pas encore d’équivalent dans WP.
Les aspects communautaires (Profile+Status+Activity) de Drupal, ainsi que la Taxonomy sont très supérieurs à WP.
Pour résumer, tant qu’on n’a pas besoin de communauté, de types de contenus spécifiques, de workflow, de taxonomy complexe, Drupal et WP sont équivalents.
merci pour ton article , tu viens de me décider à tester drupal
suite à ton article j’ ai essayé drupal en me lançant dans la traduction du module drigg ( http://jaka.fr ) . Drupal est une bombe , la prise en main est vraiment très rapide . merci
Merci pour cette comparaison très intéressante qui à l’avantage de rétablir les idées préconçues.
Concernant les résultats de référencements qui ne sont pas évoqués ici , avez vous des comparaisons d’efficacité ? Ne pensez vous pas que le Module « all in one SEO » de WP apporte un vrai avantage / aux temps de réponse des moteurs et de simplicité pour les utilisateurs ?