Clairement, l’avantage est à WordPress.

Drupal est un système très modulable, mais son « core », à la différence de WordPress, est spartiate, et dispose de peu de fonctionnalités avancées. (Un article d’Amaury vient de sortir sur le sujet. Je ne suis pas d’accord avec un certain nombre de ses équivalences, mais comme j’ai déjà expliqué pourquoi ici, j’irai répondre chez lui ^^)

L’installation elle même est très simple, un peu comme WordPress, mais on se retrouve devant un système nettement moins « prêt » à l’emploi, et qu’il va falloir tout de suite compléter par des modules (plugins dans le monde WordPress), si on veut vouloir faire ce qu’on a l’habitude de faire.

Et avant même l’installation, il faut prendre le temps de lire la doc, car il peut être intéressant de configurer dès le départ Drupal pour plusieurs sites (ce que peut se faire aussi avec WordPress).

Ensuite, à peine son Drupal installé, on va partir à la recherche des modules complémentaires, ceux qui lui donnent toute sa puissance par rapport à WordPress. Sur WordPress, on partira plutôt vers la recherche de thème.

Configurer une installation multisites

Dans Drupal comme dans WordPress, il est possible de que plusieurs sites partagent le même back-end (et je ne parle pas de WPµu, mais du WordPress normal).

Le multisites sous WordPress

Dans le fichier wp-config.php, il est possible depuis la 2.6 de définir des dossiers différents du standard pour les thèmes et les plugins, avec les quatre paramètres :

• WP_CONTENT_DIR
  define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );
• WP_CONTENT_URL
  define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');
• WP_PLUGIN_URL
  define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins');
• WP_PLUGIN_DIR
  define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

Là où ça commence à vraiment devenir intéressant, c’est quand on voit qu’il est aussi possible de partager les users de différents blogs avec
define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

Le multi sites sous Drupal

(basé sur l’excellent article de Lektum, sur le wiki Drupal France)
Il est prévu dès le départ, avec une structure de répertoires sous le répertoire sites, avec un répertoire commun à tous les sites, et un répertoire à créer par site.
Il faudra donc, avant de lancer la procédure d’installation automatique, créer au moins un répertoire de site, celui correspondant au premier site que vous voulez créer.

Les répertoires doivent être nommés en fonction des domaines :
Si le site est accessible avec l’url mondomaine.com, le sous répertoire de site sera sites/mondomaine.com
Si le site est accessible avec un sous domaine, ce sera sites/monsousdomaine.mondomaine.com
Si c’est par un sous répertoire, ce sera sites/mondomaine.com.monsousrépertoire

Ensuite, il faut faire une copie du fichier defaults.settings.php et la nommer settings.php (dans le répertoire de votre site).

Puis vous pouvez lancer l’installation automatique. Vous pouvez à ce stade modifier le préfixe par défaut des tables.

Pour lancer le deuxième site, vous devrez d’abord avoir fait pointer le nom de domaine, ou de sous-domaine, vers le dossier « drupal » global. C’est Drupal qui prendra ensuite en charge l’url rewriting.

Vous allez créer un deuxième répertoire site, copier le fichier defaults.settings.php et le renommer en settings.php, et lancer l’installation automatique (en donnant un préfixe de table différent de la première installation).

Mon conseil : qui peut le plus peut le moins, configurez toujours Drupal de cette façon, même si vous ne pensez – pour l’instant – avoir qu’un seul site.

A ce stade, en dehors des 5 minutes passées à configurer le multisite sur Drupal, l’installation de WordPress et celle de Drupal sont aussi simples. C’est ensuite que cela va se corser !

Les fonctionnalités, et les modules

Les plugins de base de WordPress

WordPress est généralement installé avec très peu de plugins : Akismet, pour lutter contre le spam, Hello Dolly, pour faire plaisir au côté musical de Matt Mullenweg. Et très honnêtement, cela peut suffire.
J’ajoute souvent :

• All in One SEO, pour générer les descriptions et les titles.
• Backupify, pour être tranquille sur les backups de données (dépêchez vous, les comptes sont gratuits jusqu’au 31 janvier)
• Exec-php et Evaluate-php (depuis la 2.9) pour pouvoir insérer du php dans mes articles (je pourrais aussi passer par des shortcodes, ça serait plus « sûr’, mais sur des blogs mono-utilisateurs, ça me gonfle).
• Google XML Sitemaps
• No Follow Free, que j’apprécie beaucoup.
• Organize Series, cet article est par exemple dans une série.
• Simple Tags, d’Amaury Balmer
• Récemment, Twitter Tools et
• WP touch pour être lisible sur un Iphone
• Links Summarizer, qui fait la liste des liens en bas de cet article.
• Subscribe to comments
• Less pour l’affichage des articles après la balise more
• Random Post Widget
• Get Recent Comments
• No Self Pings
• Et bien sûr le plus excellent de tous les plugins WordPress, Category Ancestor (autopromo sans vergogne)

C’est tout. Et surtout, vous remarquez qu’aucune des fonctionnalités introduites par ces plugins n’est essentielle.

Drupal et la chasse aux modules

Avec Drupal (6) la situation est TRES différente.
J’attends d’un site qu’il soit capable de :

• Gérer un rewriting d’url basé sur des règles -> besoin d’un module, alors que les permaliens sont dans le core de wordpress
• Gérer des « champs personnalisés », ou du contenu additionnel par type de post -> besoin d’un module, alors que les customs fields sont dans le core de wordpress
• Etre internationalisable (puisque c’est la raison pour laquelle j’ai choisi Drupal) -> besoin d’un module
• Pouvoir chercher et sélectionner un peu ce que je veux dans la base de données -> besoin d’un module (qui sera internalisé dans la version 7)
• Pouvoir charger facilement une image, créer des galeries, etc -> besoin d’un module
• Et pour mes utilisateurs, un bon éditeur Wysiwig -> besoin d’un module

Et là commence le parcours du combattant.
On télécharge un module, on veut l’activer, et on s’aperçoit qu’il dépend d’un autre module…
Par ailleurs, Drupal a un système de cache, et à chaque fois qu’on modifie quelque chose à la config, il faut vider le cache… sur mon install de développement, j’ai pour l’instant choisi de ne pas activer le cache.

Pour être honnête, il existe des Drupal pré-packagés. Malheureusement, quand on débute totalement sur un système, il est difficile de savoir quelle sera « le bon » package.

Pour en citer quelques uns :

• Acquia, distribué gratuitement par la société du même nom, fondée par Dries Buytaert, le créateur de Drupal. Pour moi, pas de bol, rien qui soit lié à l’internationalisation (en cliquant sur le lien, vous arriverez à la liste des modules)
• Drupal Builder, qui permet de construire son package, en fonction des modules souhaités. (Bon là aussi, pas de bol, pas de modules d’internationalisation, même si on peut choisir la langue du package)
• Et toute une série d’installations profiles, qu’on peut trouver sur Drupal.

En mode râleuse « on », je vais protester contre le fait que les modules de Drupal soient compressés en .rar, ce qui ne me permet pas d’ouvrir directement l’archive pour la placer dans le dossier de mon site (ceux de WordPress sont en zip, et en natif, dans Windows, je peux en ouvrir le contenu, même sans avoir acheté WinZip).

Mes modules Drupal

La liste est assez longue. Je me limiterai à mes indispensables.

i18n

Cela peut sembler étrange de le mettre en tête de mes indispensables, mais il ne faut quand même pas oublier que je suis partie sur Drupal pour gérer des sites multilingues. i18n fournit les bases de la gestion de la traduction. On peut rajouter d’autres modules, comme

• tContact, qui permet d’afficher le formulaire de contact par défaut de Drupal en plusieurs langues
• Menu Translation… comme son nom l’indique
• Taxonomy block, pour traduire les taxonomies
• Pour de gros sites, cela peut être intéressant de le compléter avec des outils comme Translation Framework et Translation Overview.
• Language icons, pour faire apparaitre des icônes pour le choix de la langue

URL rewriting, SEO, et tout ça

• On commence avec le module de base, PathAuto. Très puissant, puisque qu’il permet de définir des types d’urls par type de contenu / langue (pas oublier,… Drupal MULTILINGUE), et qu’il peut intégrer des contenus définis dans CCK.
  Donc certes un module additionnel par rapport aux permaliens de WordPress, mais énormément de puissance en plus.
• On peut, on doit le compléter par des modules de redirection, notamment pour éviter le duplicate content entre l’url de base (du type node/ qui correspond à index.php?= sur Wordpress), c’est Global Redirect et Path Redirect, qui assure les redirections en cas de changement d’url
• L’équivalent de All In One SEO, c’est Nodewords, qui permet de rajouter des metas aux contenus.
• Enfin, des modules permettent de faire une checklist. Je ne pense pas qu’ils soient indispensables pour quelqu’un qui maitrise parfaitement Drupal, en revanche, tant qu’on prend l’outil en main, c’est utile. J’utilise SEO Friends et SEO Compliance Checker
• Le sitemap de votre site peut être généré par XML sitemap

Donc là encore, obligation d’installer des modules, pour des fonctionnalités présentes dans le core de WordPress. En revanche, une fois ces modules installés, plus de fonctionnalités.

Customs Fields (pour WP), ou Content Construction Kit (CCK)

C’est un peu injuste de comparer CCK aux champs personnalisés de WordPress, c’est un peu comme comparer une draisienne et une Ferrari.
Imaginez donc des champs personnalisés que vous pourriez gérer entièrement par l’admin. Pour lesquels vous pourriez définir des règles de saisie, des contrôles, des filtres, auxquels vous pourriez attacher des autorisations d’accès.
CCK est un « Ã©norme » module de Drupal, et il vient avec toute une liste de modules, qui élargissent ses fonctionnalités.

Views et CPanels

Views est aussi un « Ã©norme module ». C’est celui qui va permettre de faire des sélections / tri de tout ce qu’on veut dans la base, pour arriver à une présentation vraiment flexible.
Views remplacera ainsi des plugin de type « most rated », « most commented », « last » etc… et permet aussi, ce qui n’est pas simple dans WordPress, de faire des sélections complexes (telle catégorie et telle autre, entre telle et telle date, avec tel auteur).
Panels, lui permet de facilement organiser la page en plusieurs blocs de contenu. C’est notamment une base pour les thèmes magazines.

Se faciliter la vie

Pour l’administrateur / développeur / intégrateur, il y a l’inévitable Administration Menu
On installera aussi Drupal for Firebug (et le même sur Firefox).
Enfin Chaos Tool Suite rend le développement plus facile.

La gestion des images

Bon là, c’est clair, Drupal n’a pas la bibliothèque de médias de WordPress, et je vous renvoie à l’article de Bruno sur son passage en Drupalerie, comme il dit…

Néanmoins, il y a des modules assez sympa, et notamment :

• Teaser Images, qui va aller pêcher une image pour l’utiliser comme vignette, y compris dans le flux rss
• Taxonomy Images, qui fait grosso modo la même chose que category icon, mais sur la totalité des taxonomies de Drupal.
• Lightbox2, bien sûr est porté sur Drupal

Le bilan

Le temps de charger / activer tout cela, de le paramétrer ensuite, avec éventuellement les droits d’accès… non Drupal ne s’installe pas en un clic, Drupal ne s’installe pas en cinq minutes, et Drupal ne s’installe pas non plus « comme ça », sans avoir au moins un peu l’idée de ce qu’on aimerait faire.

En revanche, à la sortie, on a nettement plus.

A chacun de savoir si il a besoin de ce nettement plus, et si il peut pour ce besoin, investir le temps nécessaire.

Parcourir la série

«Drupal et WordPress : deux logiques proches, mais différentes.

Tags: module, plugin

Sur le même thème

• Permaliens de catégories dans Wordpress et duplicate content (5)
• Ce blog fait du dofollow (6)
• Category Ancestor, plugin pour WordPress (3)