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.
No estoy seguro de si esto es intencional, pero quería informarlo:
Estamos en una versión estable desactualizada v3.5.4 y estábamos usando el plugin cakeday. Sin embargo, las reconstrucciones (de la misma versión de Discourse) dejaron de funcionar porque cakeday se había fusionado con el núcleo. Entonces, deshabilité el plugin en el archivo yml y… bueno, desapareció. Ahora se reconstruye de nuevo, pero ya no tenemos días de pastel ya que la interfaz de administración no muestra ninguna señal de que la funcionalidad esté instalada.
Supongo que se debe a que estamos en una versión estable desactualizada, pero aun así fue un resultado inesperado para una reconstrucción de la misma versión de Discourse.
El complemento cakeday no está incluido en la versión 3.5.4, por lo que esa es la razón por la que ya no lo ves.
¿Estás seguro de que esa es la razón por la que empezaron a fallar? Si viste algo como:
PISTA: El complemento ‘$plugin’ ahora está incluido con Discourse y no debe incluirse en la configuración de su contenedor
Entonces, me temo que eso se mostrará para cualquier reconstrucción fallida cuando el complemento cakeday esté incluido en el archivo de configuración. Esta fue la forma más eficiente que pudimos encontrar para advertir a las personas sobre el problema, pero puede ser confusa para las personas que ejecutan versiones anteriores del núcleo.
Así que, si necesitas el complemento cakeday, creo que deberías poder volver a agregarlo a tu archivo app.yml y reconstruir. Sospecho que el fallo fue causado por otra cosa, que ya has resuelto.
Como comentario al margen: te recomendaría encarecidamente que actualices a una versión compatible. La versión 3.5 ya no recibe actualizaciones de seguridad y puede ser vulnerable a ataques.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Volver a agregar el plugin a app.yml provoca el error anterior. Quitarlo inmediatamente hace que la compilación funcione de nuevo. Este plugin parece ser el único problema.
Soy consciente de que estamos en una versión desactualizada y que está en la hoja de ruta actualizar. Solo quería señalar que, aunque no hemos cambiado la versión que estamos ejecutando, 3.5.4 pasó de compilar bien (con el plugin) a no compilar más con el plugin y no parece que tengamos forma de recuperar la funcionalidad del plugin (a través del plugin o en el núcleo).
¡Interesante! Me pregunto si se debe a que nuestra imagen de docker ahora incluye discourse-cakeday, y luego cuando el núcleo se “rebaja” a 3.5, deja un directorio vacío.
Si añades rm -rf discourse-cakeday antes de la línea git clone https://.../discourse-cakeday, entonces eso debería limpiarlo. Así que se vería algo como:
Siento sacar esto un poco del tema, pero no creo que haya un tema más adecuado y está algo relacionado con el problema anterior.
Desde mi mensaje anterior, creo que se han realizado más cambios en discourse/docker_manager que están rompiendo más cosas en las compilaciones de versiones antiguas. Después de una reconstrucción hoy, toda la sección de administración de Discourse dejó de funcionar con errores como este:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
Pude solucionar la compilación usando esto en el yml:
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
No estoy seguro de cuál fue el commit ofensivo, pero esto fue suficiente para que volviera a funcionar.
Lo sé, lo sé, debo actualizar (lo digo en serio). Pero es probable que haya otras personas como nosotros que estén atrapadas en versiones anteriores más tiempo de lo planeado por una razón u otra, y que las compilaciones antiguas se rompan sin cambiar la versión es un poco inesperado.
De todos modos, ya encontré una solución temporal hasta que actualicemos, así que solo lo comparto por si es útil para otros en la misma situación.
