Si el error dice que reactions, data explorer y solved todavía están en tu archivo yml, entonces probablemente lo estén. Si crees que los comentaste, ¿podrían haber sido ingresados dos veces?
Definitivamente vale la pena revisar la configuración y asegurarte de que editaste el archivo yml que corresponde a tu sitio.
Hola
He actualizado correctamente mi foro a la última versión estable 3.4.6. Antes de esto, utilizaba el plugin independiente discourse-oauth2-basic para la autenticación.
No hay inicio de sesión Oauth2 Basic en /admin/plugins.
Mi versión de Discourse es 3.4.6.
PISTA: El plugin ‘discourse-oauth2-basic’ ahora está incluido con Discourse y no debe incluirse en la configuración de su contenedor.
Elimine la línea ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ de su archivo containers/app.yml, luego intente de nuevo.
Para más información, vea Bundling more popular plugins with Discourse core
Tengo que eliminar el plugin discourse-oauth2-basic antes de actualizar a la 3.4.6.
¿Podrían ayudarme a entender qué pudo haber salido mal?
¡Gracias!
Hmm… ¿podría ser el hecho de que estás en estable?
Siguiendo la indicación del sistema, eliminé el plugin discourse-oauth2-basic antes de actualizar con éxito a la versión estable 3.4.6.
Sin embargo, ahora he descubierto que las opciones de configuración para OAuth 2 Basic faltan en el panel de administración.
Si estás en estable, entonces nada de este tema se aplicará hasta después de la próxima versión estable a principios de agosto. Por lo tanto, deberías volver a añadir oauth2-basic a tu app.yml. El fallo original debe haber sido por alguna otra razón.
Desafortunadamente, la lógica de ‘hint’ no es muy inteligente y no es consciente de estable vs. tests-passed.
Yo también, pero ¿qué podemos hacer al respecto? jajaja. Creo que más recursos nativos, es decir, complementos, incluso si están deshabilitados, no son una buena solución para ayudar a los principiantes a autoalojarse.
@nat Mira esto, la traducción de mi cita y mi respuesta
No importa cómo intenté comentar las líneas de clonación en la sección de plugins, pero las estaba leyendo como si quisiera instalar los plugins. ¿Qué hice? Quité la línea y finalmente funcionó.
Cuando actualices, deberás verificar la lista de plugins incluidos en el núcleo de Discourse para no agregarlos en la sección de plugins para instalar o eliminar esa línea si la tienes en tu archivo app.yml.
Creo que como estos vienen preinstalados, debería haber opciones que los separen 
de la lista de instalados. Ya que la lista de instalados se puede desinstalar, a diferencia de solo poder deshabilitarlos.
Quizás los complementos fusionados principales deberían estar bajo algo como Complementos destacados. O Complementos principales.
Con, por supuesto, quizás un filtro de Todos.
Su sugerencia no es ideal, pero funciona. Ejemplo:
## Los plugins van aquí
## ver https://meta.discourse.org/t/19157 para más detalles
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
(Ajustar según se desee)
7 publicaciones se dividieron en un nuevo tema: Solución de problemas de fallos de arranque en Discourse
La realidad aquí es que la rama estable es una LTS, y bastante buena además. Recibe actualizaciones de seguridad y está bastante claro qué versiones de plugins son compatibles con ella (gracias al archivo .discourse-compatibility). Admito totalmente que tardó mucho tiempo antes de que todo esto empezara a funcionar, pero en los últimos dos años más o menos, lo ha hecho, lo cual es un gran logro del equipo.
Ahora, para la segunda parte de tu declaración. Es cierto que stable a menudo se representa como algo que no deberías querer. Pero en el hosting de Communiteq, hemos estado dando a los clientes la libre elección entre estable (“estabilidad primero, nuevas actualizaciones dos veces al año, actualizaciones de seguridad una vez al mes”) y tests-pasados (“siempre al límite, nuevas funciones una vez al mes”) durante los últimos 2,5 años y el 85% elige estar en estable.
Lo entiendo. ¿Pero no es eso un problema de desarrollo y no un problema de producción? Puedo entender totalmente que lo hagas en desarrollo. Pero añadir esos plugins en una instalación de producción por defecto va un poco en contra de la idea de tener un plugin (que por definición es algo no predeterminado).
La única ventaja real en producción que veo es el problema muy, muy marginal de desinstalar plugins y hosts multisitio. (De nuevo, ¡esto es algo bueno, todos los demás problemas de producción se han resuelto con el tiempo!)
Eso también podría haberse resuelto en el script de configuración mostrando una lista de plugins que los usuarios pueden marcar y luego añadiéndolos a app.yml.
Pero todavía ofrecéis diferentes (sub)conjuntos de plugins para diferentes niveles, ¿verdad?
Yo también habría preferido el enfoque de descomentar app.yml.
Todos estos plugins están instalados en todos nuestros planes de autoservicio. Algunos niveles no tienen acceso, pero permanecen instalados incluso si no tienen acceso.
No vamos a cambiar esta decisión, así que esto es simplemente algo con lo que la gente tendrá que vivir. Entiendo que algunas personas están molestas, algunas personas están en contra de esto, pero esto simplemente no va a cambiar.
Nos da velocidad durante el desarrollo, define nuestras preferencias, asegura que Discourse, tal como lo usa la gran mayoría de las personas, sea más estable.
Hay otros plugins… los plugins principales no son los únicos plugins.
Se dividió una publicación en un nuevo tema: Discourse no envía una versión LTS
Estoy totalmente de acuerdo en que tiene sentido mover los plugins populares y su funcionalidad al núcleo de la imagen. Especialmente si provienen de los mismos programadores (CDCK) que el núcleo en sí. Esta es una práctica común incluso para otros proyectos de software. Pero deberíamos resolver los problemas de arranque: todavía soy optimista 
Es la razón por la que no puedes reconstruir.
Este definitivamente sería el mejor camino. Todavía se puede implementar utilizando el código de eliminación de plugins en la publicación anterior.
Agregar eso al script de instalación brinda muchas mejores opciones desde el principio y es bastante común en los programas permitirle elegir si instalar o no ciertas características opcionales.
El archivo de comparabilidad es genial. Aunque, en mi humilde opinión, se debería agregar información de comparabilidad a los temas. Con un enlace o instrucciones para si el TC/plugin está disponible tanto para las instrucciones de instalación Estables como para las de Pruebas superadas.
Gracias por la guía; esto funciona muy bien, excepto por el plugin “automation”, que no se puede eliminar, ya que parece que el plugin de chat depende de él.
El plugin de automatización es algo que realmente no debería eliminarse, para ser sincero. Tiene muchos usos potenciales útiles. Se necesita más tiempo invertido en mi opinión para obtener más opciones de automatización.
Pero sí, es genial que haya una opción para organizar eliminando complementos que, como ha señalado @RGJ, las opciones verdaderamente adicionales que recientemente se fusionaron, se podría cuestionar si estas opciones son deseables para instalar. Quizás incluso un script separado para después de la instalación solo para hacer las cosas más amigables para los autoalojados, de modo que aquellos que deseen evitar tener que editar el app.yml.