Dans la dernière version de Discourse, l’utilisation des fichiers .hbs dans les thèmes et les plugins est dépréciée. La prise en charge de ce format de fichier sera supprimée après la prochaine version ESR.
Les modèles Handlebars doivent être remplacés par le format .gjs plus moderne, qui offre une bien meilleure expérience de développement et permettra d’importantes améliorations des performances dans les futures versions de Discourse.
Pour les cas simples, partagez votre code sur https://ask.discourse.com/ et demandez-lui de le réécrire au format .gjs.
Pour les cas plus complexes, les mises à jour peuvent être automatisées à l’aide de ce codemod :
Il est fort probable que nous abandonnions le support dans la version 2026.8.0-latest. Mais il est possible que ce soit plus tard, en fonction des données réelles et des retours de la communauté.
Merci ! J’espère que la plupart des gens s’en sont déjà occupés, car ils sont obsolètes avec une bannière d’administrateur depuis près d’un an. Juste au cas où, j’ai ajouté cette note :
Pour ma part, j ai essayé pour mon ptit plugin perso et j ai réussi avec l aide de ask Discourse qui a fusionné mes fichiers hbs et js en un fichier gjs.
Je conseil grandement l utilisation de ask Discourse pour résoudre ce problème pour ceux comme moi ont d des difficultés de développement
C’est super ! J’ai également ajouté une note sur ask.discourse.com dans le message initial. Si vous n’avez que quelques fichiers, cela peut très bien fonctionner
Je n’ai aucune idée de ce qu’est un fichier .gjs, ni le temps d’apprendre à les utiliser et de réécrire plusieurs plugins. C’est ridicule.
Quel est l’intérêt d’avoir une API de plugins si elle est aussi fragile que celle de Discourse ? Maintenir des plugins pour ce logiciel de forum n’a été qu’une source d’ennuis.
Si vous n’avez pas le budget ou la capacité nécessaire pour gérer des personnalisations, je vous encourage à simplifier votre configuration.
À mon avis, c’est le prix (raisonnable) à payer pour rester sur une plateforme de pointe, très réactive, qui continue d’innover, d’améliorer ses performances, de déployer fréquemment des correctifs de sécurité et de suivre l’évolution des normes.
L’équipe de Discourse semble s’investir beaucoup pour s’assurer que des messages d’avertissement de dépréciation sont envoyés bien avant la perte de fonctionnalité.
Préféreriez-vous être bloqué sur une plateforme peu sécurisée avec moins de fonctionnalités ?
Pensez à la valeur que vous tirez du noyau bien entretenu que vous pouvez télécharger gratuitement.
Mais avec l’aide de ask.discourse.com , il a lu mon code et m’a converti mon fichier hbs et js en .gjs donc il ne faut pas hésiter si la première méthode ne fonctionne pas
Notez que je comprends votre frustration : tous ceux qui ont développé des plugins, des thèmes ou des composants sont confrontés à des obsolescences et des mises à jour obligatoires.
Quelques autres expriment également leur frustration :
Je ne travaillerai plus sur aucun de mes plugins Discourse. Cela ne vaut tout simplement pas la peine.
Étant donné que deux d’entre eux sont utilisés par d’autres personnes, quelle est la procédure pour les supprimer sans causer de problèmes aux autres utilisateurs ?
J’en ai assez de les voir tomber en panne, généralement pour des raisons complètement absurdes, tous les quelques mois, ainsi que du temps et de l’effort nécessaires pour maintenir mon forum fonctionnel.
Je ne veux pas être « à la pointe de la technologie ». Je veux simplement un forum web fonctionnel et stable.
« Ne pas mettre à jour » n’est pas une option non plus, car nous avons besoin de mises à jour de sécurité. C’est ridicule que quelqu’un ait suggéré cela la dernière fois que je me suis plaint.
L’équipe Discourse doit vraiment se soucier davantage de la compatibilité et éviter de casser les forums et le code existants. Ils ne semblent même pas y réfléchir. Ils introduisent des changements incompatibles juste pour un peu mieux ranger les choses de leur côté. Ce n’est pas ainsi qu’on gère une plateforme et une API utilisées par d’autres personnes, et je ne veux plus avoir aucun lien avec cela.
Si vous souhaitez vraiment emprunter cette voie, je vous recommande d’ajouter une note dans le README et le sujet Meta, de le marquer comme broken, puis d’archiver le dépôt GitHub. De cette façon, il reste disponible pour que d’autres puissent le forker (à condition que la licence le permette).
Nous nous soucions absolument de la compatibilité et du bon fonctionnement des choses. C’est pourquoi nous avons ces longues périodes de dépréciation avec des chemins de mise à jour entièrement automatisés.
Nous cherchons toujours à trouver l’équilibre entre personnalisation et stabilité : les thèmes et plugins Discourse sont si puissants parce que nous leur donnons un accès direct aux API sous-jacentes du navigateur et du framework. Ce pouvoir immense s’accompagne d’une certaine responsabilité pour rester à jour face aux changements sous-jacents.
En effet, rester à jour est important. Au cours des derniers mois, nous avons investi massivement dans notre pipeline de publication pour améliorer considérablement les choses pour les utilisateurs ESR (anciennement « stable »). Plus de détails ici. Vous devez toujours mettre à jour, mais il y a beaucoup plus de flexibilité concernant le timing et l’urgence.
En ce qui concerne cette dépréciation spécifique, la solution est entièrement automatisée. Si vous pouvez nous indiquer les noms des plugins, nous serons heureux d’exécuter le codemod pour vous et de soumettre une PR. Nous l’avons fait pour tous les 600+ thèmes/plugins que nous maintenons, c’est donc un mécanisme bien huilé à ce stade.
Je comprends que ce ne soit pas facile de revenir après quelques mois et de constater que beaucoup de choses ont changé. Se tenir à jour face aux évolutions peut être difficile, mais à mon avis, c’est le prix à payer pour un logiciel de forum de pointe doté d’une API étendue.
Alors pourquoi continuez-vous à apporter des changements motivés par le nettoyage de petits détails superflus de votre côté, au détriment de la compatibilité ?
Ces éléments obsolètes font partie du prix à payer pour maintenir une plateforme ou une API. Ils ne posent aucun problème réel. Pourtant, vous insistez pour les modifier ou les supprimer, ce qui oblige les autres à effectuer des travaux supplémentaires et des tests.
Les versions ESR ne durent que 9 mois, ce qui constitue à peine un support étendu.
De plus, leur utilisation signifie simplement que vous devrez faire face à tous les changements cassants d’un coup, avec une liste beaucoup plus longue de commits à parcourir si vous essayez de comprendre pourquoi un problème s’est produit.
L’ESR tel qu’il existe aujourd’hui aggravera ce problème au lieu de l’améliorer.
La seule solution est de prendre réellement soin de l’API et de la maintenir. Ne procédez à des changements cassants qu’en dernier recours, et non pour de petits « nettoyages » facultatifs. Et ne jetez pas un framework entier utilisé par les gens simplement parce que vous avez envie d’en utiliser un autre, ou pour toute autre raison.
La procédure ici consiste à utiliser les versions ESR en production et les versions mensuelles ou les versions « tests validés » en staging.
Si vous mettez à jour l’environnement de staging quotidiennement, hebdomadairement ou mensuellement – vous pouvez même automatiser cela – vous pourrez mettre à jour vos plugins et thèmes de manière itérative et les maintenir en état de fonctionnement.
Le fait de conserver les versions ESR en production vous offre une marge de manœuvre d’au moins trois mois pour corriger les problèmes.
Vous semblez incapable de comprendre qu’une API publiée ne doit pas être une cible constamment mouvante.
Imaginez si Microsoft obligeait tous les développeurs Windows à modifier leur code tous les six mois. C’est impensable. Vous pouvez prendre du code écrit pour Windows 95 il y a 30 ans et le compiler et l’exécuter sur une machine moderne aujourd’hui sans aucun changement.
Vous ne pouvez pas prétendre vous soucier de la compatibilité alors que le code écrit selon vos spécifications cessera de fonctionner en raison uniquement des décisions que vous avez prises.
