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.

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 !

Articles relatifs

• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Utilisation originale de WordPress comme CMS : une documentation ! (8)