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 !
31 réponses à “Drupal vs WordPress : Les modules de base”
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 ( https://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 ?
C’est parfait comparaison. Selon moi Drupal et WordPress sont au même niveau, mais la plupart des gens aiment utiliser WordPress comme comparer à Drupal.
Tout à fait d’accord avec « Marie-Aude » le premier commentaire. Déjà bien des rapport de comparatifs entre cms ne sont pas bien réalisé et pas avec le bonne méthode.
Comparer des cms entre eux c’est dans un bute aussi trouver des cms utilisable en milieu professionnel.
On ne compare pas les possibilités d’un cms seulement avec ses plugins c’est souvent l’erreur qui est faite ! Il est vrai que cela peut en faire partie mais ca n’est pas sur cet argument que l’on effectue un rapport de possibilité. Il ne suffit pas non plus de connaitre tout le coeur des cms pour pouvoir comparer.
Et surtout WordPress & drupal ne sont pas comparable ils ne jouent pas dans la même cours.
Là où tu as raison c’est que WordPress est un cms mais de type mixte on pourrait dire blog/Portail.
Drupal comme joomla peut être utilisé pour quasiment tout type de site ou voir certaine application web, intranet ou extranet.
Wordpress ne permet pas de réaliser un site communautaire aux droits d’accès poussée ca c’est une certitude. Drupal oui et permet de créer bien d’autres types de réalisation.
professionnellement j’utilise typolight, cms made simple (très polyvalent aussi comparable à typolight mais typolight est plus puissant), Spip, Joomla (mais gare aux failles de code du CORE hélas) et drupal.
En équivalent dans les grandes lignes de certains CMS :
EZpublish = SPIP : on utilise spip plutôt que EZpublish car il consome bien moins de ressource, bien moins complexe et bénéficie d’une très grande Doc bien fournit.
Typo3 = Drupal ou Joomla : pourquoi utiliser un cms qui bouffe autant de ressource si ce n’est plus qu’un drupal, plus complexe à prendre en main qu’un drupal (pour faire de simples choses), petites communautées, pas assez de plugins trop complexe pour un résultat simple.
etc… pour d’autres cms.
Si on veut realiser un site très spécifique et bien moi je développe sous symfony tout simplement pourquoi se prendre la tête avec un framework intégrer comme ezupublish ? après chacun son tripe :)
merci pour cet article en tout les cas toujours utile et clair je trouve même si il y a des erreurs c’est en partageant que l’on avance :)
Globalement d’accord avec TheShadoO, sauf que d’une part une très grande majorité de clients n’ont pas besoin d’une usine à gaz, mais ont bel et bien besoin d’une solution simple qu’ils pourront utiliser, qu’ils ont besoin d’une solution performante en termes de référencement, et que, oui et j’assume, WordPress peut être utilisé comme un CMS – moyennant certaines limitations certes, mais dont la majorité des clients n’ont que faire – et qu’avec certains développement, il peut aussi très bien devenir un système Intranet…
L’avantage d’utiliser WordPress ou une autre plateforme, est bel et bien de ne pas devoir réinventer la roue à chaque nouveau projet. Y compris pour des sites très spécifiques.
Bien entendu cet avis n’engage que moi ! :-)
Tout à fait d’accords, mais là où est justement la force de Drupal, c’est que tu peux carrément customiser l’admin vue qu’il n’y a pas vraiment une séparation entre le backoffice et le front en rapport avec les autres cms.
Ce qui signifie que dans drupal que peux très bien une admin complètement allégé pour l’utilisateur. Lorsque l’on arrive dans l’admin de drupal, on s’y perd au premier abord je dis bien en tant que super admin/ développeur. Depuis la version 7 de drupal énormément de soin a été apporté à l’ergonomie et le core.
J’avais fait un site prote folio en drupal pour une photographe, son administration était complètement épuré, donc lorsqu’elle se loguait elle le faisait en tant que sub admin et cela lui donnait accès à seulement ce dont elle avait besoin, c’est à dire l’upload de photo, la création de catalogue, déposer des commentaires et d’autres petites choses.
C’est bien là la force de drupal, il est extrêmement customisable jusque dans l’admin, beaucoup de webagency qui créait des sites en drupal laisse l’admin tel quel mais pourtant on peut tout à fait le customiser (je ne parle pas du theming backoffice).
bonjour,
existe-t-il la possibilité sur drupal de préparer des articles en avance et de les publier automatiquement (pré-publication) comme cela est possible avec wordpress ?
j’ai le sentiment que sur drupal on n’a que le statut publié / non publié…
merci de vos réponses
Drupal semble tout de même plus difficile à prendre en main ?
WordPress l’ideal pour alimenter son blog perso . et Drupal pour faire un CMS pro ou le fait de modifier les pages est essentiel pour le client par exemple.
C’est qui me saoule avec wordpress c’est le temps de charge.
Le fait de ne pas pour le faire évoluer facilement par exemple créer 3 pages avec dans chacune d’elle des articles.
Super cet article, d’autant qu’ici à mon boulot on a switché de Xoops à Drupal pour les « gros sites », et je garde WordPress pour les mini-site ou des choses que je veux créer moi même sans avoir besoin d’une équipe !
J’ajoute ton site à mes flux RSS, car je sens que je vais y lire plein de trucs intéressants !
Je trouve que Drupal est plus compliqué à prendre en main que WordPress. Je pense aussi, comme il a déjà été dit ici, que Drupal et WordPress ne concours pas dans la même catégorie de CMS.
nice stuff nice pages and nice blog
Super article, il y a peu j’ai testé Joomla et Drupal parce que je trouvais wordpress de plus en plus lourd a utilisé pour des projets du genre 3 pages avec des articles de differentes catégories affichées dans chacune d’elle … il faut obligatoirement toucher au code source avec WP !
Pour Drupal son système d’administration incorporé à la page est sympa et la taxinomie il faudra que je test plus.
Pour Joomla, je suis conquis … je vais m’y intéresser fortement, rien qu’a voir le panneau d’administration on vois le monde de différence (je trouve)
SPIP, TYPOLIGHT et SYMFONY je vais tester en local mais je me spécialiserais dans un seul.
Ca me parait pas très logique d’aller vers Drupal et Joomla, si tu trouves WP « lourd ».
« projets du genre 3 pages avec des articles de differentes catégories affichées dans chacune d’elle » : c’est justement le type de projets pour lesquels WP est fort (moteur blog…).
J’utilise wordpress depuis quelques années mais sérieusement devoir passer par le code source et dépendre de plugin je trouve cela pénible de plus en plus… maintenant il est évident que si je dois proposer une plate forme blog je reste avec WordPress, mais pour l’ecommerce ou des sites vitrines je vais tenter Magento et Joomla.
Merci pour ta réponse rapide en tout cas, tu n’utilise que WP ?
Bon c’est pas compliqué, moi je suis à fond sur Drupal… et comment dire WordPress c’est très bien pour faire un petit site classique ou un blog, si tu veux un site avec des services spécifiques, soit tu trouves le plugin miracle qui fait exactement ce que tu veux ou sinon tu fais du dev spé.
Avec Drupal, déjà on oublie tout de suite le petit site ou blog (c’est possible, mais il y a WP pour ça). Drupal c’est fait pour faire du lourd, du communautaire; grâce à d’astucieuses combinaison de modules tels que cck, views, pathauto, menubreadcrumb,… (je vous laisse chercher, c’est le petit jeu du débutant sur drupal.org) on peut faire à peu près tout ce qu’on veux (des annuaires, des communautés, des plateforme de blog, des portail média, des applis complexes,…), en fait il ne faut pas voir Drupal comme un CMS classique, mais plutôt comme un framework avec une interface utilisateur pour faire le dev (au lieu de mettre dans le code), auquel on ajoute des fonctionnalités en installant des modules. Ayant réalisé un grand nombre de sites sur Drupal, je n’ai fait que très peu de dev spé, et quand c’est le cas, ça se résume en quelques lignes de code.
Au niveau de la prise en main, WP et u jeu d’enfant, Drupal un peu plus complexe au départ (mais bon si vous faites des sites vous êtes pas des noobs et vous parlez anglais, donc pas de soucis… il faut juste être patient et organisé. Après pour vos clients, on me dit souvent que Drupal c’est compliqué pour les utilisateurs finaux… tout faux, au contraire vous pouvez faire une interface d’admin (en front, il n’y a pas de back dans drupal) limitée au seul besoin de votre client.
Le dernier point et pas des moindres : l’hébergement
– un WP s’installe facilement et à peu près sur n’importe quel serveur
– Drupal vous demande un peu plus de connaissance en terme de serveur, et c’est même pas la peine d’installer un drupal sur des hébergements lowcost (premières offres OVH, 1&1,…). il faut absolument que vous puissiez éditer les valeurs php de votre serveur (certains mutualisé le permettent). En gros l’idéal c’est d’avoir son propre serveur dédié (ou virtuel dédié)
Merci pour ce très bon article et merci à tous ceux qui ont pris le temps de commenter.
Cette page est une mine d’infos pertinentes.
Je voudrais revenir sur un des éléments qui pour moi reste le plus grand enjeu de cette discussion.
Nous parlons de CMS : un outil de gestion de contenu. Ayant dit cela nous admettrons que l’on ne monte pas un CMS pour nous (« nous » les gens qui comprenons le code qui est derrière) mais pour des personnes qui n’ont pas ces connaissances.
Alors je dis et je soutiens que le véritable enjeu du choix d’un CMS, c’est de choisir le bon outil vis à vis de la facilité qu’auront ses utilisateurs à l’utiliser.
Autant dire que je bosse la plupart du temps avec WordPress (oui la gestion des images et médias et vraiment plus simple pour ma belle mère….).
Pour avoir eu l’occasion de bosser sur Drupal je reconnais que c’est une bombe.
Ne serait-ce que par la structure des données, on peut aller plus loin qu’avec un WordPress.
Par contre les efforts à fournir pour offrir une expérience a peu près intuitive à mes utilisateurs (clients) sont plus importants sur Drupal.
Me semble-t-il….;)
J’ai testé Drupal, et je préfère de loin WordPress. On peut supprimer certains menus de l’interface d’administration en ajoutant ce code, dans un plugin ou dans le fichier functions.php du thème:
function remove_menu() {global $menu;
unset($menu[5]); /* supprime le menu "Articles" */
unset($menu[15]); /* supprime le menu "Liens" */
unset($menu[25]); /* supprime le menu "Commentaires" */
}
add_action('admin_head', 'remove_menu');
Dire que drupal est relativement facile à utiliser si:
– on n’est pas noobs,
– on connaît tant soit peu l’anglais,
– si l’on a déjà bidouillé sur d’autre cms,
– si l’on a du temps devant soi,
– si vous avez compris du premier coup la vision de drupal,
– si les aides que, par hasard, (ben oui, vous avez tout compris…)vous demandez ont des réponses,
– si….
Avec des si, on met Paris en bouteille.
J’ai un drupal installé, et comme je suis un noobiz, j’attends toujours des explications sur tel ou tel module, depuis quelques jours, et plus. Views, par exemple, et Média. Placer des images, ça va encore, mais les videos…Rien ne marche. Ce qui est le comble pour un site qui se veut « universel ».
Bien sur que les possibilités de drupal sont très fortes, mais, à force, l’usine à gaz n’est pas loin. J’ai connu Oracle, qui me semble plus facile que Drupal, même en version 8. Quant à la communauté drupalienne, les derniers messages et réponses s’arrêtent en …2009/2010.
Bref, WordPress, c’est pas mal. Et il est très simple de mettre les mains dans le cambouis pour aller sur les fichiers des thèmes. C’est où, sous Drupal ?
Complètement d’accord avec ce dernier commentaire ! Le choix de Drupal se fait à la fois lorsque le client a des besoins assez complexes ou lorsqu’il s’agit d’un gros site avec un besoin de fonctionnalités spécifiques nécessitant du développement.
Je ne comprends personnellement pas qu’on apprécie de travailler avec SPIP et encore moins avec Joomla ! oO
Le choix de drupal peut aussi être par simple plaisir.
J’ai essayé Joomla – pas longtemps – et Spip, qui , tout compte fait n’est pas trop mal.
J’attends toujours des réponses de Drupal… :)
Drupal n’est pas un CMS comme les autres, il peut faire tourner un blog, un site d’actualité, mais là où il est fort c’est quand on a besoin des besoins hors du commun (gros sites, intranets, contenus personnalisés). Le comparatif qui est ci-dessus est orienté WordPress, beaucoup d’outils savent faire un peu tout. Les modules les plus importants de Drupal c’est CCK (la possibilité de créer des champs personnalisés) et Views (afficher n’importe quel champ comme on veut).
Si les 2 seuls avantages de Drupal sont CCK et Views, alors WordPress n’a rien à lui envier !
Attention, ne vous méprennez pas ! wordpress peut largement recevoir de fortes montés en charge au contraire ! Drupal et joomla aussi logique, mais pour sa petite taille wordpress justement recevoir énormément de charge et beaucoup de contenu tout comme spip.
wordpress comme spip sont dédié à la base à des sites de publication, et notamment wordpress peut accueillir beaucoup beaucoup de contenu bien plus que 5 malheureuses catégorie et quelques articles. Il y a des gros site au même titre que le parisien ou autre aux us, canada ou france qui tournent sous wordpress.
Ce qui peu alourdir wordpress ce sont des plugins, où fonction mal codé voir trop des widgets lourd. il existe des plugins afin de profiler les plugins de wordpress qui prennent trop de ressources, pensez à les utiliser.
Si non pour recommenter cet article, le gros problème de wordpress je trouve c’est certain gestion des données en base, rapide mais illisible et difficile de modifier certaine chose ainsi qu’un code full procédurale alors qu’il consomerait (attention je ne dis pas que wordpress consome de la ressource) dix fois moins de ressources si il était recodé en full objet.
Une doc trop disparate, un code trop four tout, d’un certain côté on peu comprendre que certain développeur aient mal codé leur plugin mais bon. Ayant déjà programmé des plugins sous wordpress j’essaie d’avoir un pattern un peu plus objet afin de factoryser mon code au mieux.