En la última versión de Discourse, el uso de archivos .hbs en temas y complementos está obsoleto. El soporte para este formato de archivo se eliminará después de la próxima versión ESR.
Las plantillas Handlebars deben reemplazarse con el formato .gjs más moderno, que proporciona una experiencia de desarrollo mucho mejor y permitirá grandes mejoras de rendimiento en futuras versiones de Discourse.
Para casos sencillos, comparte tu código con https://ask.discourse.com/ y pídele que lo reescriba en el formato .gjs.
Para casos más complejos, las actualizaciones se pueden automatizar usando este codemod:
¿Entiendo correctamente que la versión 2026.7 seguirá siendo compatible con los archivos hbs y que la 2027.1 será la primera versión de ESR que no lo sea?
Lo más probable es que dejemos de dar soporte en 2026.8.0-latest. Pero es posible que sea más tarde, dependiendo de los datos del mundo real y los comentarios de la comunidad.
¡Gracias! Espero que la mayoría de la gente ya se haya ocupado de ellos, ya que han sido obsoletos con un banner de administrador durante casi un año. Por si acaso, agregué esta nota:
Por mi parte, lo intenté para mi pequeño complemento personal y lo logré con la ayuda de ask Discourse, que fusionó mis archivos hbs y js en un archivo gjs.
Recomiendo encarecidamente el uso de ask Discourse para resolver este problema a aquellos como yo que tienen dificultades de desarrollo
No tengo ni idea de qué es un archivo .gjs, ni tengo tiempo para aprender sobre ellos y reescribir varios plugins. Esto es ridículo.
¿Cuál es el punto de tener una API de plugins si es tan frágil como la de Discourse? Mantener plugins para este software de foro ha sido un problema constante.
Si no tienes el presupuesto o la capacidad para gestionar personalizaciones, te instaría a simplificar tu configuración.
En mi opinión, es el precio (razonable) que pagas por permanecer en una plataforma de vanguardia y alta velocidad que sigue innovando, mejorando el rendimiento, implementando parches de seguridad frecuentes y se mantiene al día con los estándares en evolución.
El equipo de Discourse parece dedicar mucho esfuerzo a garantizar que haya mensajes de advertencia de obsolescencia con mucha antelación a la pérdida de funcionalidad.
¿Preferirías quedarte atrapado en una plataforma insegura con menos funciones?
Piensa en el valor que obtienes del núcleo bien mantenido que puedes descargar de forma gratuita.
Ten en cuenta que entiendo tu frustración; todos aquí que han desarrollado plugins, temas o componentes enfrentan depreciaciones y actualizaciones obligatorias.
No voy a realizar más trabajos en ninguno de mis complementos de Discourse. Simplemente no vale la pena.
Dado que otras personas están utilizando dos de ellos, ¿cuál es el proceso para eliminarlos sin causar problemas a los demás?
Ya estoy harto de que se rompan, generalmente por razones completamente absurdas, cada pocos meses, y de la cantidad de tiempo y esfuerzo que requiere simplemente mantener mi foro funcionando.
No quiero estar “a la vanguardia”. Solo quiero un foro web que funcione y sea estable.
“No actualizar” tampoco es una opción, ya que necesitamos actualizaciones de seguridad. Es ridículo que alguien haya sugerido eso la última vez que me quejé.
El equipo de Discourse realmente necesita preocuparse más por la compatibilidad y por no romper foros y códigos existentes. No parecen ni siquiera pensarlo. Realizan cambios que rompen la funcionalidad solo para ordenar ligeramente las cosas de su lado. Eso no es gestionar una plataforma y una API que son utilizadas por otras personas, y no quiero tener ninguna parte más en esto.
Si deseas proceder por este camino, te recomendaría añadir una nota al README y al tema Meta, marcándolo como #roto y luego archivando el repositorio de GitHub. De esta manera, seguirá disponible para que otros lo hagan fork (suponiendo que la licencia sea lo suficientemente permisiva).
Nos preocupamos absolutamente por la compatibilidad y por mantener todo funcionando. Por eso tenemos estos largos periodos de depreciación con rutas de actualización completamente automatizadas.
Siempre estamos tratando de encontrar el equilibrio entre la personalización y la estabilidad: los temas y complementos de Discourse son tan poderosos porque les damos acceso directo a las APIs subyacentes del navegador y del framework. Ese inmenso poder conlleva cierta responsabilidad de mantenerse al día con los cambios subyacentes.
Efectivamente, mantenerse al día es importante. En los últimos meses hemos invertido fuertemente en nuestra cadena de lanzamiento para mejorar las cosas significativamente para los usuarios de ESR (anteriormente ‘estable’). Más detalles aquí. Todavía necesitas actualizar, pero hay mucha más flexibilidad en cuanto al momento y la urgencia.
En cuanto a esta depreciación específica, la solución es completamente automatizada. Si puedes indicarnos los nombres de los complementos, estaremos encantados de ejecutar el codemod por ti y crear una PR. Lo hemos hecho para todos los 600+ temas/complementos que mantenemos, por lo que en este punto es un mecanismo bien engrasado.
En este post, sugerí añadir la etiqueta #sin-mantenimiento o la etiqueta #fin-de-vida.
Entiendo que no es fácil si uno vuelve después de unos meses y descubre que ha cambiado mucho. Mantenerse al día con los cambios puede no ser sencillo, pero en mi opinión es el precio a pagar por un software de foro de vanguardia con una API extensa.
Entonces, ¿por qué sigues haciendo cambios impulsados por la limpieza de pequeños restos de código innecesario de tu parte, a costa de la compatibilidad?
Esa suciedad heredada es parte del precio de mantener una plataforma o una API. No causa problemas reales. Pero insistes en cambiarla o eliminarla, lo que obliga a otras personas a realizar trabajo adicional y pruebas como resultado.
Las versiones ESR solo duran 9 meses, lo que difícilmente constituye soporte extendido.
Además, usarlas solo significará que tendrás que lidiar con todos los cambios disruptivos de una vez, con una lista mucho más larga de commits que buscar si intentas entender por qué ocurrió un problema.
La ESR tal como está hoy empeorará este problema, no lo mejorará.
La única solución es realmente preocuparse por la API y mantenerla. Realizar cambios disruptivos solo como último recurso, no para pequeñas “limpiezas agradables”. Y no descartar un marco completo que la gente está usando solo porque sientes que quieres usar otro, o por la razón que sea.
El proceso aquí consiste en tener la producción en ESR y el entorno de pruebas (staging) en las versiones mensuales o en las que han pasado las pruebas.
Si actualizas el entorno de pruebas cada día, semana o mes (incluso puedes automatizarlo), podrás actualizar de forma iterativa tus plugins y temas y mantenerlos en un estado funcional.
El hecho de que mantengas la producción en ESR te da un margen mínimo de tres meses para solucionar los problemas.
Parece que no logran comprender el concepto de que una API publicada no debe ser un objetivo en constante movimiento.
Imaginen si Microsoft obligara a todos los desarrolladores de Windows a modificar su código cada seis meses. Es impensable. Pueden tomar código escrito para Windows 95 hace 30 años y compilarlo y ejecutarlo en una máquina moderna hoy sin realizar ningún cambio.
No pueden afirmar que les importe la compatibilidad cuando el código escrito según sus especificaciones dejará de funcionar debido únicamente a las decisiones que han tomado.
