7 mois de développement de zod.kr, 5 mois après l’ouverture : choix du CMS et développement

Suite de l’article https://fr.news.hada.io/topic?id=19746.

Cet article explique pourquoi Rhymix a été choisi pour construire un site communautaire coréen, ainsi que le processus de développement du site avec Rhymix.

Ci-dessous, le résumé de ChatGPT.

---

Résumé du retour d’expérience sur le choix du CMS et le développement de zod.kr (version courte)

• Contexte : l’auteur a jugé l’écosystème coréen des CMS trop vieillissant, mais a décidé d’utiliser un CMS existant plutôt que d’en créer un nouveau pour des raisons pragmatiques.
• Comparaison des CMS :
  • Gnuboard5 : écarté à cause de problèmes de qualité du code, de sécurité et de structure.
  • Rhymix : familier car basé sur XE, avec une structure améliorée, la prise en charge d’une syntaxe moderne et une bonne extensibilité → choix final.
• Points forts de Rhymix :
  • De nombreuses fonctionnalités modernes, comme Composer, une architecture modulaire, la prise en charge du cache et des files asynchrones.
• Points faibles :
  • Interface d’administration datée, écosystème tiers incomplet, documentation insuffisante, etc.
• Design : utilisation d’un thème responsive, avec correction de nombreux bugs et améliorations en CSS/JS.
• Ajout de fonctionnalités :
  • Implémentation maison de nombreuses fonctions, dont les web push, la gestion d’événements, les uploads intégrés à R2 et des fonctionnalités utilisateur.
• Développement de modules : faute de manuel suffisant, l’auteur a dû analyser le code et comprendre lui-même la structure pour implémenter les modules.

👉 En résumé : dans un environnement CMS vieillissant, Rhymix a été choisi comme solution réaliste, et zod.kr a pu être construit de manière stable au prix de nombreux essais, erreurs et personnalisations.

[jujumilk3]

Merci beaucoup pour ces informations très précieuses sur le développement et l’exploitation réels du site, je les lis avec grand intérêt.

[nemorize]

En tant qu’utilisateur qui utilise XE depuis ses débuts, puis Rhymix jusqu’à aujourd’hui depuis plus de dix ans, je me reconnais beaucoup dans ce constat.

À mon avis, le plus gros problème est que la majorité du marché visé par Rhymix n’a pas vraiment les compétences nécessaires pour développer elle-même.

Les personnes capables de développer par elles-mêmes choisissent souvent Laravel ou autre, plutôt que d’accepter la documentation insuffisante de XE ou Rhymix, leur structure parfois ambiguë et leurs aspects legacy.

Comme l’auteur du billet original, moi aussi, je continue d’adopter Rhymix pour quelques nouveaux projets, notamment pour :

1. une interface d’administration que beaucoup trouvent familière
2. des fonctionnalités de CMS qui, malgré quelques regrets, restent complètes
3. une équipe core qui intègre activement les nouvelles propositions
4. l’attachement accumulé au fil des années
   etc.

Mais à chaque fois, je me demande sérieusement si c’est vraiment le bon choix.

J’essaie personnellement plusieurs approches pour compenser les points qui m’ont déçu lorsque j’ai utilisé Rhymix comme substitut de framework.
https://github.com/nemorize/rx-make (branche develop / projet PoC, pas de mise en production prévue)

Je teste diverses pistes, comme transformer Rhymix dans son ensemble en framework/bibliothèque, minimiser l’accès aux API legacy, ou encore reconstruire des API plus modernes tout en restant à peu près compatibles avec l’existant legacy... mais j’y réfléchis vraiment énormément haha...

Je n’avais jamais vraiment mis cette réflexion au clair, mais je pense que c’est l’occasion de l’organiser une bonne fois pour toutes de manière plus nette.