Creo que lo que sugieren es que si un plugin que ya estaba incluido con el núcleo se listara en app.yaml, simplemente se ignoraría. Con una notificación que indicara que incluirlo en app.yaml era redundante y que el propietario podría eliminarlo.
Yo también encuentro un poco molesto que mientras tenga cualquier plugin listado en mi app.yaml, siempre corro el riesgo de una actualización fallida. Así que cada vez que hago la actualización, necesito verificar dos veces para ver si alguno de mis plugins ha sido agregado al núcleo.
¿Por qué no simplemente tener un script que lo haga por el Sysop?
Yo mismo organizo los plugins por equipo o autor para hacerme la vida un poco más fácil, así sé qué plugins son oficiales y demás. Pero si la idea es hacer Discourse más fácil de usar, eso debe hacerse en el extremo del equipo.
No es realmente tan diferente cuando aconsejaste a la gente cuando un usuario tiene una actualización rota debido a un fallo de actualización de Postreq (¿así?).
Con los plugins, aquí es exactamente donde el concepto del Instalador Procourse fue una gran idea para simplificar la instalación y desinstalación de plugins sin necesidad de usar la línea de comandos.
Es cierto que entiendo que podría haber necesitado un poco más de pulido en caso de que algo saliera mal. Pero eso podría ser lo suficientemente fácil con un archivo de registro o una simple opción de recuperación si fuera necesario desde la línea de comandos. Aprecio que esto pueda hacerlo más atractivo para el autoalojamiento en comparación con un plan de pago. Sin embargo, hay suficientes pros para un plan de pago para seguir esa ruta.
Este tipo de gestor de plugins también podría ser creado o bifurcado para permitir que los planes alojados instalen plugins dentro de su nivel alojado, ya que algunos plugins pueden no ser necesarios en el plan específico.
De hecho, me perdí una publicación de hace mucho tiempo sobre que el chat estaba incluido y había intentado instalarlo. No creo que la etiqueta se actualizara en el plugin. Por supuesto, bloqueó el sitio, ya que no le gustó que intentara instalar el plugin cuando, en teoría, podría haberlo ignorado, con una reconstrucción completa que indicara que podría eliminarse por ser innecesario.
Con la reciente iniciativa de agrupar más plugins oficiales en el núcleo, me preguntaba si el plugin Who’s Online está siendo considerado para su inclusión.
He notado que está disponible en los planes de hosting oficiales (contando para la cuota de plugins), así que tengo curiosidad si eso indica un movimiento hacia una adopción más amplia.
Entiendo totalmente si las restricciones de rendimiento o el ajuste filosófico significan que debe permanecer desactivado por defecto a menos que se especifique lo contrario en el app.yml.
Actualmente no planeamos mover más plugins al núcleo. Cakeday fue el último, y tuvo que hacerse por separado del lote principal debido a algunas complicaciones con la forma en que se habilitó previamente por defecto.
Entiendo completamente la frustración sobre el proceso aquí, ciertamente no es tan fluido como me gustaría. Para dar algo de contexto: el problema fundamental es que los archivos app.yml no son un archivo de configuración de Discourse. Son una configuración de pups, y las líneas de instalación de plugins son solo comandos de shell.
Incorporar lógica específica de Discourse en pups, y hacer que ignore ciertos comandos de shell, no es realmente una opción. Esta herramienta no se usa solo para Discourse. Además, sospecho que a muchas personas no les gustaría que cambiáramos los comandos de shell que se ejecutan durante el arranque sin su conocimiento.
Así que llegamos a la solución más limpia que pudimos encontrar con las herramientas disponibles: forzar una reconstrucción de la CLI y luego mostrar un mensaje pidiendo a la gente que elimine la línea afectada de su configuración.
Piensa cuidadosamente antes de instalar este plugin
Creo que “instalar” podría expresarse mejor como “habilitar” allí, si eso es técnicamente correcto.
La redacción actual podría dar la impresión de que tener plugins adicionales incluidos es una preocupación filosófica o de rendimiento, cuando en realidad solo se trata de si están habilitados. Dado que un plugin recién incorporado que no estaba habilitado antes se deshabilita por defecto después de la reconstrucción, el riesgo no está en tenerlo instalado con el núcleo, sino en activarlo.
Ahora ese problema específico se ha resuelto (en su mayor parte) en los complementos incluidos, pero en otros complementos esto podría seguir ocurriendo aquí y allá.
El plugin discourse-categories-suppressed añade una interfaz de usuario simple y opcional para ocultar categorías seleccionadas del feed “Latest”. Se integra a través de un único menú desplegable en:
Administrador → Configuración → Categorías
“categorías suprimidas de la página principal”
Esto parece una configuración central muy natural, especialmente porque:
• Es oficial y se mantiene activamente.
• Permanece deshabilitado por defecto a menos que un administrador lo active.
• Muchas comunidades (incluida la mía) dependen de “Latest” como la vista principal y desean un control más fino sobre lo que aparece allí.
¿Consideraría el equipo incluir este plugin (aún deshabilitado por defecto), para que los administradores puedan usar este interruptor sin necesidad de instalar nada adicional?
Gracias por considerarlo. Parece una pequeña preferencia de interfaz de usuario que muchos sitios se beneficiarían de tener disponible de inmediato.
