L’installation, les plugins et les modules
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.
Concernant le multisite, autant utiliser WordPress Mu, bien plus adapté que la technique évoquée ci-dessus !
Sauf que MU ne marche pas dans toutes les configs sur un hébergement mutualisé, par exemple sur les mutus 1&1 la création de sous domaine par wildcard n’est pas possible ^^
Salut Marie-Aude
Tu parles du plugin wordpress Evaluate-php mais ton lien ne semble pas pointer où il faut https://wordpress.org/support/topic/plugin-exec-php-shows-php-code-on-non-homepage-post-listings?replies=4%29
As-tu la bonne adresse ?
Car je voulais utiliser exec-php mais il ne semble pas compatible avec l’éditeur visuel : http://bluesome.net/post/2005/08/18/50/#wysiwyg_editor
Merci d’avance
Bonsoir Olivier,
en fait le lien pointe vers la discussion du forum où le fix est expliqué. Il faut faire son plugin soi même.
Je ne pense pas qu’il permette de travailler avec l’éditeur visuel pour autant.
Honnêtement, je ne pense pas que WordPress et Drupal soit des produits concurrent, chacun à sa spécialité. WordPress le blog, Drupal le … euh non il n’a pas de spécialité à part de fournir un conteneur IoC et d’être une usine à module.
Je ne pense pas non plus que WordPress soit limité au blog. Notamment avec BuddyPress, il dépasse largement cela.
Effectivement, les deux produits ne sont pas concurrents, mais ils peuvent tous les deux répondre aux mêmes types de besoin (je dis bien types) et c’est en creusant dans les détails qu’une solution ou une autre va s’imposer.
ton article est très complet…
je me suis un peu casse les dents sur les modules d’internationalisation de drupal…
A propos du module views, pour “customizer” les fields via le php c’était pas mal aussi…
mais après quelques heures a se pendre avec une documentation pauvre ( a part biboo.net qui est très bon), le résultat est plutôt sympa.
g essayer aussi joomla et c’etait un vrai calvaire… la plupart des modules sont payant, très peu documentés et parfois plein de bug…
a+ chez drupal…
J’ai eu aussi des problèmes, j’ai du recommencer ma première install quatre fois, il y a quelque chose que je gérais mal au niveau des droits et je bloquais régulièrement.
Quant à Joomla, le problème, c’est surtout que la logique est totalement différente. J’ai trouvé dans la doc Drupal un excellent article sur le “changement de paradigme”, en gros avec Joomla on construit la structure et on met le contenu ensuite, alors que dans Drupal, on peut faire du contenu et le structurer de façon souple.
Super article franchement !
J’utilise Drupal depuis 3 ans et je ne suis pas développeur php, je suis webdesigner-intégrateur.
J’ai un petit peu installé WP mais sans plus.
Ma question est la suivante :
Une fois les installations réalisées au point de vue du développement et de la croissance future…
Lequel de Drupal ou WP pourra supporter le fait de passer d’un simple site (ou blog pour ceux qui disent que Drupal n’est pas fait pour des blogs) à un plus gros site conséquent ? (Gestion contenu, …)
Je ne parle pas d’installation de modules ou autres … mais vraiment de la gestion des contenus vraiment plus conséquennt…
J’hésite vraiment entre WP et Drupal pour un projet très énorme.
Merci
@++
C’est difficile à dire, tout dépend aussi de la structure du contenu. Drupal a par nature beaucoup plus de tables que WordPress, avec par exemple une table pour chaque “custom field” (anciennement CCK dans Drupal), ce qui est “a priori” une hérésie d’un point de vue MySQl, mais qui permet aussi de faire des minis requêtes. A l’inverse, WordPress met tout dans une table… Drupal doit rapidement être utilisé avec un système de cache, quand WordPress peut facilement s’en passer. Cela dit, quel que soit le CMS un projet “très énorme” doit être finement tuné, par des connaisseurs.
Oui c’est sûr l’énormité du projet va vraiment jouer dans le choix…
Je ne suis pas assez connaisseur pour y répondre… me faudrait plus d’infos spécifiques. Tx