Le point de départ de la réflexion est d’essayer de tirer parti de la « puissance » de WordPress pour créer, et maintenir, des sites éditoriaux comme on le ferait avec un CMS (Drupal, Joomla, etc.). On laisse de côté dans cette réflexion les plugins permettant, par exemple, de gérer un forum ou des sondages avec WordPress.
Historiquement, WordPress permet de gérer des blogs, c’est-à-dire une succession de « posts » (billets) que l’on peut éventuellement catégoriser et qui sont affichés en ordre ante-chronologique (le plus récent en premier). WordPress apporte également toute la mécanique permettant de commenter ces billets.
Très rapidement, WordPress a introduit la notion de « pages » permettant la création de contenus éditoriaux qu’on pouvait rendre disponibles en positionnant des liens vers ces pages dans les menus. Toutefois, les « pages », si elles permettent de créer du contenu de façon libre (texte riche), ne permettent pas d’avoir véritablement une approche structurée des contenus.
Ce besoin de contenu structuré est très présent quand on veut gérer, dans la durée, un site éditorial efficace, en particulier si on veut confier cette gestion à des utilisateurs « non informaticiens ». En effet, si on est capable de différencier facilement les types de contenu (par exemple les fiches formation, les références client ou encore les offres d’emploi), il est également possible plus simplement et de façon plus efficace de maîtriser la façon dont on affiche ces contenus.
WordPress a bien compris ce besoin et a introduit (depuis la version 2.9) la notion de « custom post types« . Cette notion permet de créer des types de « posts » spécifiques en sélectionnant tout ou partie des attributs disponibles en standard. En combinant cette notion avec les taxonomies, il est possible de créer et de gérer des contenus différenciés et, partant, de spécialiser l’affichage de ces contenus.
Une autre approche est disponible (depuis fin 2008), il s’agit du plugin « pods« . Il permet, facilement, de créer un nouveau type de contenu avec des attributs également typés (texte, date, nombre par exemple, mais aussi relation avec d’autres types de contenu, y compris les « posts » et « pages »). Il permet également de gérer des contrôles (appelés « helpers ») qui sont appelés lors de la création de contenu ou lors de l’affichage. Il permet aussi de gérer des vues (appelés « templates ») pour l’affichage des contenus (liste / détail). Ce plugin peut être combiné avec le plugin « pods ui » pour une meilleure intégration dans l’interface d’administration de WordPress. Il convient d’ailleurs de noter que ces deux plugins vont être fusionnés lors de la sortie (prévue pour juillet 2011, visiblement retardée) de la version « 2.0 » du plugin.
Sans vouloir me lancer ici dans un débat d’expert sur les performances ou sur les avantages comparés (cf. ici ou encore là), j’avoue avoir un faible pour l’approche « pods » (et en particulier pour les promesses de « pods 2.0 ») qui me semble plus aboutie.
N’hésitez pas à donner votre avis dans les commentaires…