- Drupal et WordPress : deux logiques proches, mais différentes.
- L’installation, les plugins et les modules
En furetant sur les forums Drupal, je vois que pas mal de personnes envisagent, comme moi, de passer de l’un à l’autre, soit pour migrer leur blog, soit pour construire un autre site web, plus complexe, pour lequel WordPress ne peut pas tout faire.
Or même si les concepts sont après tout assez proches (un CMS reste un CMS), le vocabulaire, et surtout l’organisation des fonctionnalités n’est pas la même, et passer d’un système à l’autre peut être assez déroutant.
WordPress est un excellent système de blog, qui peut faire beaucoup d’autres choses, grâce à des extensions et des plugins.
Drupal est un CMS qui peut gérer un blog, un forum, ou des publication, mais dont les fonctionnalités sont moins « pré packagées » que dans WordPress. (On le verra avec l’installation).
On peut utiliser WordPress out of the box, sans plugin, en choisissant simplement un thème plaisant, et avoir un site « bien fini ». C’est impossible avec Drupal, il va donc falloir rajouter des modules. Et pour rajouter les modules dont on a besoin… comprendre la logique de Drupal.
Les structures de base
Les contenus de Wordpress
La structure de base de WordPress, c’est l’article (le « post »), qui se trouve dans la table wp-posts. Il y a quatre types de contenus possibles : l’article au sens « article de blog », la page (pour la différence entre les deux, voir cet article), la pièce attachée (l’image chargée par la bibliothèque des medias) et la révision (quand la gestion des versions n’a pas été désactivée).
L’article peut avoir des informations annexes, ce sont des « metas », qui sont stockés dans une table à part. Ces valeurs correspondent aux custom fields, ou champs personnalisés.
Et c’est tout.
Les contenus de Drupal
La structure de base de Drupal, c’est le « node », ou le noeud.
Le node est lui aussi un contenu.
La première différence avec WordPress, c’est que le type de contenu n’est pas limité.
Drupal est livré avec quelques types par défaut (Page, Article) mais on peut en créer autant qu’on veut dans l’administration.
Or l’avantage de créer des types de contenus différents, c’est qu’on peut ensuite les personnaliser : en y rajoutant des champs supplémentaires (pour ceux qui ne connaissent que WordPress, imaginez des Custom Fields auxquels on peut rajouter des règles de saisie très détaillées), des autorisations, des règles différentes pour la réécriture des urls. Et aussi, des sélections différentes.
L’organisation et la classification du contenu
Là la différence entre les deux systèmes est très forte.
Catégories et tags chez Wordpress
Au début était la catégorie, et seulement la catégorie. Depuis sont arrivés les tags. Tags et catégories sont les « termes » (ou taxonomie) qui permettent de qualifier et donc classer un article (et récemment une page).
En conséquence, un article doit obligatoirement avoir une catégorie.
Les pages, elles s’organisent comme un ensemble indépendant, qu’on peut structurer, en donnant une page fille à une page mère (ou père, si vous voulez).
Les catégories peuvent aussi être hiérarchisées. Pas les tags.
Les fonctions qui permettent de lister les catégories et les pages (wp_list_categories et wp_list_pages) sont utilisées pour faire les menus.
Taxonomies et menus chez Drupal
A la différence de WordPress, le truc obligatoire chez Drupal, c’est le menu. En effet, c’est par le biais du menu qu’on va permettre d’accéder aux nodes.
On peut avoir autant de menus qu’on veut, mais il faut avoir un menu primaire.
Et pour chaque node, on décidera de l’affecter (ou pas) à un élément de menu, ou pas (si on ne l’affecte pas à un menu, on pourra quand même y accéder).
Les taxonomies ou termes, sont extrêmement souples. Comme le reste, elles se paramètrent par l’interface d’administration. On peut en créer autant qu’on veut, leur donner des valeur par défaut, … alors que dans WordPress, il faut obligatoirement mettre les mains dans le code si on veut gérer des taxonomies supplémentaires (ce que fait par exemple le plugin Organize Series).
« The Loop » ou les « Views »
Le mécanisme de base de WordPress, c’est la « boucle » qui passe a travers les posts, et qui détermine une sélection à afficher. Les sélections de base sont « tout, en ordre chronologique décroissant », « les articles d’une catégorie », « les articles d’une période donnée », « les articles d’un auteur », et après si on veut faire plus complexe, il faut mettre les mains dans le code, avec query_posts().
Ce mécanisme ne fonctionne pas de la même façon dans Drupal.
La détermination de ce qui s’affiche se fait par le biais des menus.
Et par les « vues ».
« Views » étant un des modules les plus utilisés de Drupal, un des trucs de base qu’il faut installer si on veut avoir un site un tant soit peu fonctionnel.
Imaginez un système qui vous permette d’utiliser the query, mais d’une façon graphique, un peut comme on trie des champs dans excel.
Et de décider ensuite où vous l’affichez dans votre site.
Les thèmes
La grande différence entre WordPress et Drupal, ce sont les blocs.
Dans WordPress, on a un système de template php assez classique avec une hiérarchie (page d’index par défaut, puis pages spécifiques pour les catégories, les auteurs, les archives), et des fichiers spécifiques qui vont apparaitre sur la toutes (ou certaines) pages, le header, le footer, les sidebars.
Lesquelles sidebars vont présenter des informations comme la liste des catégories ou des pages (des « menus » de Drupal), la liste des derniers commentaires, des meilleurs articles, des articles au hasard (des « vues dans Drupal). Et aussi accueillir des widget, qui peuvent afficher un texte, un compteur, bref, des tas d’éléments « en dehors » de la boucle.
Dans Drupal, il y a aussi a peu près la même architecture, avec des fichiers .tpl.php, le fichier de base étant « page.tpl.php » (à la différence de WordPress, où c’est l’index). Mais avant cela, dans le thème, on va définir des blocs. Ces blocs vont être placés dans les templates.
Et ensuite on va affecter à un bloc un contenu, que ce soit un menu, un noeud, une vue, etc…
Par ailleurs, comme pour WordPress, il est possible de définir un template « spécifique » par rapport à un template général. Pour créer une page d’accueil différente, il me suffit de créer un fichier page-front.tpl.php
Il y a donc beaucoup plus de souplesse et de richesse pour organiser son contenu, sans toucher au code, ou a minima. Mais plus de travail pour préparer la présentation de ce contenu.
Deux modèles de données différents
Cela se voit tout de suite à la taille de la base de données. Une vingtaine de tables pour un site avec WordPress, une centaine pour un site avec Drupal.
Cela a plusieurs conséquences :
- la prise en main et la création du site est plus longue, plus complexe, moins intuitive avec Drupal qu’avec Wordpress
- techniquement, il est impératif d’activer le cache sous Drupal
- Le transfert d’un système à l’autre est loin d’être simple
Choisir Drupal uniquement si on en a vraiment besoin
On a vraiment besoin de Drupal si on a besoin :
- D’un site intégré avec un forum, et une identification unique des utilisateurs
- Une gestion réelle des utilisateurs, avec des autorisations un peu plus complexes que les rôles basiques proposés par WordPress
- Un site véritablement multilangue
- Une gestion complexe des contenus
En choisissant Drupal on perdra :
- le pré-packaging de Wordpress (éditeur visuel, gestion des médias)
- la richesse des thèmes gratuits prêts à l’emploi
- la possibilité pour ceux qui connaissent php de mettre très simplement les mains dans le cambouis (on peut les mettre aussi avec Drupal mais c’est moins simple)
- la légèreté de la base, qui permet d’héberger WordPress sur des offres bas de gamme, comme free
Migrer de WordPress vers Drupal
Ce n’est pas simple, et beaucoup moins simple que de migrer de Blogger ou MT à WordPress. A une table WP correspondent trois tables Drupal. Il faut par ailleurs savoir ce que l’on va faire des champs personnalisés.
La préparation de la routine d’importation pour des gros sites prend entre un et deux jours.
Pour des petits sites, sans champs personnalisés, cela peut se faire rapidement par le biais des flux xml. Mais pourquoi donc migrer un petit site vers Drupal ?
Et à partir du moment où on utilise les champs personnalisés, la routine d’importation devient nettement plus complexe.
La série d’articles « De Wordpress à Drupal » est faite au fur et à mesure de ma prise en main de l’outil. Il se peut donc qu’il y ait des inexactitudes, ou des incompréhensions.
Pas de tags pour cet article
Article tout bonnement excellentissime !
Personnellement, je pense que Wordpress vaut Drupal très largement.
Wordpress est d’ailleurs en train de délaisser son image de « blog manager » pour celle d’un CMS complet et puissant.