Tags : , , .

Gestion avancée de contenu dans WordPress

WordPress est un système de gestion de contenu très performant. Il souffre pourtant de son image de moteur de blog, objectif pour lequel WordPress avait été créé l’origine. Cependant WordPress a désormais plus de 6 ans d’existence puisqu’il a été créé en 2003 et 6 ans il s’en passe des choses. WordPress est aujourd’hui passé du statut de plate-forme blog à celui de CMS, voire pour certains à celui de framework. Je vais m’efforcer ici de donner un aperçu les fonctionnalités avancée de gestion de contenu de WordPress et de changer ainsi la perception qu’ont certaines agences butées mal informées [1] des possibilités de ce logiciel.

Mise à jour : ce billet date un peu. Pour des informations à jour sur la gestion de contenus dans WordPress, consultez la mise à jour de 2013.

Grâce aux custom fields on peut tout faire avec un WordPress : catalogue de produits, calendrier d’évènements, annuaire de membres, blog (et oui) etc… Seul problème, si vous souhaitez mettre en place dans le même site sous WordPress un catalogue de produits ET un blog, ça coince. WordPress gère difficilement plusieurs types de contenus différents. Heureusement il existe plusieurs solutions pour gérer ça : 2 plugins et une solution manuelle (comprendre coder). Ma préférence va à la solution dite ‘manuelle’ car cette solution s’adapte forcément à tous les besoins – vu que c’est du custom.


  1. Le plugin Pods
  2. La solution Custom
  3. Le plugin Flutter
  4. Conclusion
  5. Le débat est ouvert

Vu que cet article est archi long, je me fends pour vous chers lecteurs d’un petit sommaire. C’est pas sympa ça ? Si. Je sais.


Pods

pods

Pods est un plugin qi permet de créer de multiples contenu sous WordPress. La manipulation en est assez compliquée – il faut être développeur pour pouvoir l’utiliser correctement. Pods est vraiment puissant puiqu’il permet de créer différent types de contenus et de composer des relations entre ces différents contenus. Clairement, c’est ‘équivalent du plugin Content Construction Kit (CCK) dans Drupal.

Pods présente par contre l’immense inconvénient de gérer ces nouveaux types de contenu à part : les contenus créés avec pods n’apapraissent pas dans WordPress. En fait ce n’est dinalement pas une solution si intégrée que ça. Après avoir cherché la solution pour intégrer les contenu pods dans la recherche, je suis tombé sur ce message qui ‘a dissuadé d’utiliser pods pour des projets complexes

Search : That was the difficult part I must admit, because that is one thing the developers of Pods haven’t done yet, or haven’t thought about. The standard WordPress search doesn’t search in the Pod database.
Hacking into the core of WordPress is of course not an option (if you update your WordPress, hacks are bye bye). Together with a colleague we found a way to use the Pod system itself to perform the search functionality. This means that if you are planning a Pod site, you don’t need the WordPress search anymore.

En gros, on se prive d’une des fonctionnalités du coeur de WordPress : la recherche – ce que je considère personnellement comme un facteur bloquant pour l’utilisation d’un plugin.

Back to the sommaire gentiment composé par Grégoire


La solution Custom

toots

Là encore, il faut être développeur pour la mettre en place mais grâce à l’article de Ferodynamics.com et au plugin qu’il offre généreusement en téléchargement, ça devient beaucoup plus facile. L’auteur de cet article explique comment il crée un plugin pour gérer un nouveau type de contenu dans WordPress, les toots (qui ressemblent en fait fortement à des tweets). Le tout est réalisé à l’aide de 4 fichiers qui créent de nouveaux tags et une nouvelle boucle pour afficher les toots. Les toots sont en plus indexés par le moteur de recherche de WordPress.
if (have_toots()) : while (have_toots()) : the_toot();
the_toot_title
the_toot_date
the_toot_content
the_toot_rewind

Plus léger en code (4 fichiers seulement) en maintenance et en requêtes, cette méthode offre en plus l’immense avantage d’être réutilisable puisqu’elle est prend la forme d’un plugin.

Back to the sommaire gentiment composé par Grégoire


Flutter

flutter

Flutter est un plugin moins puissant que Pods mais beaucoup beaucoup plus simple à mettre en oeuvre et  à utiliser. Problème : Flutter est codé avec les pieds. Le plugin comporte pas moins de 60 fichiers et dossiers. Dur de s’y retrouver si jamais vous tombez sur un bug. Car c’est un autre problème de Flutter : il n’est pas encore toujours pas stable et certaines fonctionnalités telles que l’upload d’images sont encore bancales. Selon la configuration de votre serveur il vous faudra mettre les mains dans l’amas de fichiers qui compose Flutter. Vous pourrez éventuellement vous faire aider par les auteurs de ce plugin… sivous avez de la chance. Car c’est encore un des autres problèmes de Flutter : le plugin n’est pas open source : il est développé par la société Fresh Out qui l’utilise pour ses propres clients. En gros si vous tombez sur un problème que les clients de Fresh Out ont rencontré, vous avez des chances de voir ce problème réglé dans une prochaine mise à jour. Sinon, vous devrez vous débrouiller seul.

Flutter présente beaucoup plus d’inconvénients que d’avantages. Cependant… Il se pourrait que Flutter se retrouve à terme plus ou moins intégré à WordPress ou au moins repris en main par l’équipe d’Automatic (la société qui édite WordPress) comme l’atteste ce billet. Lors d’un WordCamp auquel Matt Mullenweg assistait, celui-ci aurait déclaré être très intéressé par les possibilités offerte spar Flutter et vu que celui-ci était codé avec les pieds il allait faire en sorte qu’il fonctionne un peu mieux.

I really like what you’re doing with Flutter, but I don’t like how the plugin works… So I’m gonna make it better

Voilà pourquoi malgré tous ses défauts Flutter est finalement très prometteur. On peut imaginer qu’à terme – pourquoi pas dans une version 2.9 – cette fonctionnalité soit intégrée au coeur de WordPress. Un Flutter bien codé serait alors un véritable Drupal Killer : il ferait tout ce que fait le module CCK (à part quelques fonctionnalités très avancées) en beaucoup plus simple et dans avec interface un peu moins soviétique que celle de Drupal.

Back to the sommaire gentiment composé par Grégoire


En conclusion

WordPress dispose de plusieurs solutions pour gérer des contenus multiformes sous forme de plugin ou à coder soi-même. Les plugins présentent l’avantage d’être des solutions clés en mains mais le gros inconvénient d’avoir été codé par quelqu’un d’autre. Autrement dit,  à moins de participer au développement de Flutter (ce qui n’est pas possible car il n’est pas open source) ou de Pods, je déconseille l’utilisation de plugins. Pour un site sérieux en production, je recommande clairement l’utilisation de la solution custom sous forme de plugin à coder soi même. Un peu plus long mais beaucoup plus maîtrisable.

Back to the sommaire gentiment composé par Grégoire

  1. Je dis agences butées mal informées car chaque fois que je dis : je suis spécialisé en WordPress, on me répond Nous on fait pas de blog ici et puis WordPress c’est trop simple. S’ensuit un couplet sur Dès qu’on a un projet avec des utilisateurs, on utilise drupal et pour les projets un peu plus simples, on utilise Spip. Et là, je me dis – in peto, vu que c’est en général un rendez-vous professionnel – mais espèce de naze, tu peux faire un site multi-user avec WordPress, un blog avec Drupal ou un forum avec Spip si ça te chante, le seul truc important c’est ton degré de maîtrise de l’outil et la simplicité de l’interface du CMS que tu vas livrer à ton client. Mais non, vu que le gars que j’ai en face est en général un chef de projet et qu’il a lu quelque part que Drupal c’est bien pour gérer des utilisateurs, que WordPress ça fait du blog et que Spip c’est simple parce que c’est en français, c’est comme ça et pas autrement. Il y aurait tout un billet à écrire sur la bonne mauvaise utilisation des outils en agence à cause du manque de compétence des décideurs en amont. Ayé, je sais que désormais je ne bosserai jamais pour une agence.

Réagissez

Si ce billet vous a plu ou si vous voulez apporter des précisions, ou si vous n’êtes pas d’accord avec ce que je raconte, c’est ici qu’il faut vous manifester. Je me réserve toutefois le droit de supprimer toute contribution insultante ou qui n’aurait rien à voir avec la choucroute.

  1. Ils en parlent ailleurs

    Francis Chouquet

    Gestion de contenu avancée avec WordPress : http://tinyurl.com/yagow7q #cms #wordpress (via @Barbayellow)

  2. Ils en parlent ailleurs

    J-Christophe Brebion

    Excellent article! RT @Barbayellow: Gestion de contenu avancée avec WordPress : http://tinyurl.com/yagow7q #cms #wordpress

  3. Excellent billet. Bravo pour ce résumé.

  4. Excellent article…

    Quelques projets Drupal à mon actif ; je l’adore pour sa gestion des content types. Par contre pour le reste, on ne va pas se mentir, Drupal reste lourd pour parfois souvent des choses simples !

    Du coup, je suis justement en train d’étudier ces différentes pistes pour un site immobilier (annonces location / vente, blog, …) que j’aimerais réaliser sous WordPress plutôt.

    Bref, ton article tombe très bien. Vais tester un peu la méthode custom ‘Toot’ que je ne connaissais pas encore.

    Si qqun à d’autres pistes, je suis preneur…

  5. Merci Grégoire pour cette éclairage. J’ai testé pour ma part Flutter et c’est une véritable usine à gaz qui nécessite de la maintenance et qui pourrait ne pas suivre l’évolution du coeur de WP. Et les solutions qui créent d’autres tables dans la base sont également à proscrire si l’on veut une gestion simplifiée de son site et la compatibilité avec l’évolution de WP et des autres plugins.

    Je suis pour une solution avec les champs personnalisés, mais l’avenir radieux de WordPress en tant que CMS passe par je pense par la taxonimie (des classeurs de tags) qui permet de relier les données entre elles. Elle permett en plus de créer des pages Urlrewrittées dédiées à ces tags (voir plusieurs tags dans WP2.9). Les tags ont également un champs description qui permette de mettre tout un tas d’infos si nécessaire.

  6. Cet article montre bien qu’il n’y a pas encore de solution stable sur WordPress pour une gestion de contenu avancée. Pods est effrayant, Flutter bordélique… Peut-être que WP est encore un peu « jeune » dans la cour des CMS et que l’offre devrait s’étoffer, que ce soit dans le coeur du système ou en dehors.

    Personnellement, je reste à l’écart de ces solutions rien que pour le fait que l’utilisateur n’y comprends rien et laisse vite tomber la gestion des autres contenus…

    Maintenant, concernant les agences, il y en a heureusement qui ont essayé WP pour autre chose que des blogs et qui maintenant continuent à l’utiliser. Cela dit, ça reste une minorité…

  7. Mouais, je ne suis pas convaincu, l’article est interessant, les méthodes instructives mais WordPress n’est pas aussi efficace que certains outils dédiés à la Drupal ou MODx quand il s’agit de sortir du cadre du blog ou du portfolio.

    C’est bien de pouvoir le plier à sa volonté, mais c’est beaucoup de temps de consommé pour obtenir un résultat plus facile à maintenir via d’autres plateformes.

    Et puis sincerement, vive la concurrence, WordPress excelle dans son domaine et est dépassé dans d’autre? whatever.

    Chaque outils correspond à un type de demande.

  8. @lossy : Vive la concurrence bien sûr. Cependant je pense que le plus important dans le choix d’un CMS c’est le degré de maîtrise que l’on en a. Et si tu es dans le cadre d’une prestation, d’un site que tu dois livrer à un client, vient à peu près au même niveau la facilité d’utilisation de l’outil pour le client. Pour reprendre tes exemples, je ne connais pas MODx mais clairement je ne livrerais jamais un site réalisé avec Drupal à un client. C’est un CMS très puissant mais avec une interface complètement imbitable par un novice. Après, que le marteau soit rouge, vert ou bleu, on s’en fout – du moment qu’on sait l’utiliser.

  9. @ lossy : C’est clair que la concurrence a du bon et que WordPress ne sait pas encore faire de la gestion complexe de contenus. Cela dit, comme le dit justement Grégoire, il ne faut pas uniquement le mettre dans la case « blog », il sait faire bien d’autres choses, tout en restant simple à gérer que d’autres feront aussi bien mais de manière moins « agile » pour l’utilisateur. Ne l’oublions pas dans cette discussion. Pour lui, entre un Drupal et un WordPress, y a pas photo ! Cela dit, ja’ttends de voir ce que va donner Drupal 7 à ce niveau là ! ;-)

  10. Salut

    Je ne connaissais pas Pods, merci, et ça me parait très intéressant. A étudier.

    Pour Flutter j’ai aussi remarqué les bugs, c’est déroutant.
    Il y a un autre plugin très similaire à Flutter, c’est More Fields.

    La différence principale entre les deux, c’est au niveau BDD, Flutter utilise des tables spécifiques, alors que More Fields utilise les tables de WordPress. Ca peut avoir une incidence suivant les besoins.

    Custom Field Template me parait solide aussi mais je n’ai pas testé.

  11. Merci pour vos réponses.

    Honnêtement, je pense que WordPress à plusieurs trains d’avances en ce qui concerne l’interface d’administration comparé à quasiment tous les autres CMS.

    En revanche, le systeme de template n’est pas la panacée actuellement, et surtout, le fait de devoir hacker le core de wordpress pour obtenir certaines fonctionnalités n’est pas engageant si une mise à jour de sécurité doit être faite.

    Plus que WordPress en tant que CMS (même pas framework), j’espere que la concurrence arrivera à remonter au niveau de wordpress pour le côté sympathique et accessible de l’admin.
    Au niveau flexibilité, les autres sont vraiment en avance, mais complètement à la ramasse quand il s’agit de fournir une interface compréhensible rapidement (presque sans formation) pour le client.

  12. @lossy : On est clairement d’accord !! :D

  13. Je rejoinds accés l’idée de Grégoire, en ce qui concerne l’utilistaion de WordPress.
    Wordpress est et deviens de plus en plus un CMS accés complet, ce n’est pas non plus un monstre de guerre, mais souvent bien assez puissant pour les clients.
    Lorsque vos clients demande un site administrable, simple à utiliser, qui leur permettra une évolution facilement, il est difficile de leur fournir un CMS comme Joomla….
    Il se mettent en général à trembler rien qu’à la présentation de l’interface administrateur.

  14. Ils en parlent ailleurs

    actus et trouvailles de début novembre | les Korrigans libres

    [...] un billet très intéressant (encore un) sur wordpress comme cms ou framework et la description très complète de plugins qui m’étaient [...]

  15. Parfois c’est le client qui impose le logiciel (parce qu’il le connait, parce que quelqu’un dans son entourage l’utilise) et au final vous impose d’utiliser WordPress comme un autre CMS, et effectivement on peut arriver à quelque chose de sympa.

    Maintenant, je connais des développeurs qui sont spécialisés sur un CMS, et qui poussent ces logiciels très loin. Perso j’essaye de choisir le CMS en fonction des besoins du client et de mes compétences.

    Je me suis volontaire limité à SPIP, WordPress et Typo3 pour la gestion de contenu.

  16. Ces plugins semblent intéressants, nous avons justement développé un plugin dernièrement, Xev SEO Auto-Linker sous wordpress et il faut avouer que WordPress n’est pas toujours très logique.

  17. c’est cet aspect « pas toujours très logique », pour paraphraser AQC qui m’a poussé il y a deux ans vers joomla. Maintenant, je me tate pour retenter l’expérience WP mais je constate qu’il n’est pas toujours mûr (dans le sens manipulable aisément par n’importe qui) même si je suis toujours impressionné par les sites développés sous WP (ceux qui en valent la peine cela va de soit).

  18. Ils en parlent ailleurs

    Youcef ES-SKOURI

    Gestion avancée de contenu dans WordPress http://icio.us/juzwhx

  19. Ils en parlent ailleurs

    Wordpress comme un CMS | Blog Multimédia - Intranet - ecommerce - Webmarketing

    [...] Bien sur, si vous voulez vous lancer dans l’ecommerce ou dans un très gros site nécessitant d’être connecté à un ERP, WordPress n’est évidemment pas une solution à envisager. Quelques réserves : WordPress gère dans sa version de base des pages et des articles. Il n’est pas pratique si l’on souhaite gérer d’autres types de contenus. Ce que Drupal fait très bien avec CCK et les Views, WordPress le gère encore très mal, bien que des solutions pour créer des types de contenus existent et sont en cours d’amélioration. [...]

  20. Bonjour,

    article intéressant. Je suis d’accord sur l’analyse des différents plugins, et notamment sur les défauts de CPods que j’ai intensivement testé. Mais pourquoi dites vous qu’on ne peut pas gérer plusieurs types de contenus ?

    Sinon, pour l’éternel débat WordPress – blog / Drupal – utilisateurs / Spip … euh ils font comment dans les pays où ils ne parlent pas français ? ^^ j’utilise beaucoup WordPress, y compris pour des « sites », mais il faut être honnête, pour l’instant WordPress n’a pas le workflow de Drupal. Tiens par exemple, comment pouvez vous filtrer les formats de saisie par type de contenu et utilisateur ?

    Quoiqu’il en soit, la gestion des types de contenus est dans le pipeline pour WordPress (ça commence avec la v3.0).

  21. Ils en parlent ailleurs

    Julien Verkest

    RT: @drupalistic: RT @spouyllau via @lumieredelune Gestion avancée de contenu dans WordPress http://blog.barbayellow.com/?p=1416

  22. @marie-aude >> Drupal est clairement supérieur à WordPress sur le workflow. En même temps, pour avoir travaillé avec des cms qui intégraient un workflow pour la publication de contenus, à l’usage, ce genre de procédure est lourde à gérer et on simplifie souvent le workflow – la simplification pouvant aller parfois juqu’à la suppression pure et simple ! Pour gérer un site edit, ce n’est pas un pré requis à mon sens. Par contre, dans une administration ou un organisme avec un structure très lourde et hiérarchisée, je ne dis pas.

  23. Bonjour

    Juste pour signaler que Flutter n’évoluant plus, un développeur en a repris le concept et a créé MagicFields, un plugin vraiment très intéressant que j’ai déjà utilisé sur deux projets.

    Je n’ai pas été regarder si c’était codé avec les pieds ou pas, quoi qu’il en soit ça fonctionne, et bien :-)

    (super pratique pour créer des back-offices sur mesure ; je l’ai utilisé sur deux projets : une agence de locations de vacances – encore en cours de dév. – et une agence immobilière, pour la gestion des implantations géographiques… Couplé à Geo Mashup pour la géolocalisation, c’est une tuerie !)

    Quant à gérer plusieurs types de contenus, une fois que l’on connaît la méthodologie, ce n’est vraiment, mais alors vraiment plus un problème :-) (surtout avec Magicfields)

  24. Personnellement, après avoir testé Pods et Flutter, j’en suis venu à la conclusion que le mieux était de développer soi-même en fonction des besoins du client ce qui manquait à WordPress.

    Cela dit, cette méthode ne me donne pas entièrement satisfaction, du fait notamment du modèle de données de WordPress …

    Dès lors, j’attends avec impatience de GROSSES évolutions dans WordPress… mais là, je rêve sans doute !

    J’ai récemment écrit un article sue ce qu’il me paraît manquer dans WordPress pour en faire LE CMS de référence… http://www.acs04.fr/archives/1132/wordpress-je-taime-moi-non-plus

    Il y a sans doute encore beaucoup à dire sur le sujet; et les différents commentaires lus ici en sont la preuve

  25. Bonjour

    Je ne suis pas trop d’accord ACS04, car depuis l’écriture de cet article (qui commence à dater) de très nombreuses nouveautés sont apparues dans WP et dans le petit monde des plugins qui y sont consacrés, et en premier lieu :
    - les custom taxonomies
    - les custom types
    - les custom fields

    Avec des plugins adaptés (notamment le trio More Types, More Fields et More Taxonomies) et un soupçon de code, on fait quasiment désormais ce que l’on veut de WordPress.

    Dernier exemple en date : le site de l’élevage de chats de mon épouse, que j’ai refait de A à Z. Les chatons dispos sont un type de post, les reproducteurs un autre type (je n’ai dans ce projet pas utilisé de custom taxonomies car je n’en avais pas l’intérêt)

    Exemple sur la page des reproducteurs :
    http://www.chatterie-koolkat.com/chats-de-race/males-et-femelles/

    Au niveau du back-office, j’ai un onglet « Reproducteurs », où je peux manager mes repros avec des champs spécifiques à ces derniers, fortement typés : le pied total !

    Autre exemple de projet (en cours de finition) sur lequel j’ai travaillé et implémenté toute l’architecture (custom types + custom taxonomies) : http://recettes.chezunchef.com/

    Du gâteau ! En fait grâce aux trois plugins cités (More …) on fait littéralement (et « graphiquement » depuis le back-office) ce que l’on veut en matière d’interface de saisie et de stockage de données fortement typées.

    Et ça, c’est une petite révolution avec WP (version 3.0 ou ultérieure)

  26. Oui, Cédric, tu as raison concernant les dernières évolutions de WP, en particulier depuis la version 3…

    Mais, cela dit, il y a encore beaucoup à faire au niveau de certaines fonctionnalités pour éviter de passer par des extensions qui ne sont pas toujours la panacée

  27. @Cedric, @ ACS04 >> cet article date de plus d’un an désormais. Depuis, le modèle de données de WordPress s’est vu ajouter ce qui lui manquait le plus : les Custom Post Types, lesquels permettent de créer autant de type d’article que l’on souhaite. Comme le dit Cédric, avec les custom post types, les custom fields et les custom taxonomies, on peut faire beaucoup de choses. Après plugin ou pas plugin, c’est un choix. Personnellement je préfère en utiliser le moins possible et n’utilise que les plugins dont je sais qu’ils sont vraiment robustes et bien codés.

    Concernant les manques de WordPress dont tu parle dans ton article, ACS04, sur le chapitre « modèle de données », il faut bien comprendre que quel que soit le CMS que l’on utilise, WordPress, Drupal, Joomla ou Spip, il faut s’adapter à la logique mise en place par les créateurs de ces logiciels. Lorsque tu propose de créer de nouvelles tables dans WordPress, là, ce n’est pas la philosophie de ce CMS. Si tu aimes bidouiller le modèle de données, je te conseille d’utiliser SPIP, lui est bien taillé pour aller chercher des infos dans des tables externes au système de base. Par contre ce n’est absolument pas la philosophie de WordPress. C’est ce qu’explique Will Norris lors d’un WordCamp qu’il donnait à Portland dans sa présentation : How not to write a WordPress plugin : If you think you need an extra table, think again. La philosophie de WordPress est de tout stocker dans les objets existants, que ce soit dans la table générale d’option ou dans les objets de type post, page, custom post types, ou même (mais là c’est encore un peu bancal) dans les objets de type user. Dans cette même présentation, Will Norris expliquait également que ce n’est pas forcément un atout d’être un dev web chevronné pour travailler avec WordPress. En effet un dev web bien formé regardera le modèle de données de WordPress et aura envie de le plier à ses besoins, de rajouter des tables par exemple. Or encore une fois, ce n’est pas l’idée dans WordPress. Pour le coup c’est plutôt dans la logique Drupal par exemple.

    Attention donc à ne pas se tromper dans le choix de ses outils : WordPress n’est qu’un simple CMS et non un environnement de dev. Pour la publication de contenu, c’est parfait, pour réaliser une application et donc modifier un modèle de données, ce n’est pas du tout adapté. Mieux vaut dans ce cas passer par un CMF comme Drupal donc ou carrément par un framework à la Code Igniter, Symfony ou Cake.

Laisser un commentaire