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.

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 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

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 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.