No recibí este aviso. Pero seguí el registro de errores y eliminé las líneas. Volviendo a reconstruir ahora.
Editar: Aparte de introducir errores y 20 minutos de inactividad, si estas líneas de complementos no se eliminan antes de actualizar; ¿Por qué realmente necesitamos esta carga adicional de complementos preinstalados?
Tengo curiosidad sobre el panorama general. ¿Cuál es la razón para incluir estos complementos por defecto?
Personalmente, se siente un poco como la dirección que han tomado Windows, los sistemas operativos móviles y algunos programas al agregar más componentes preinstalados por defecto (CARGA) que muchos de nosotros generalmente tratamos de evitar.
Estoy seguro de que este cambio probablemente se discutió con la comunidad antes de implementarse. Si es así, no es necesario que responda repetidamente, solo incluya un enlace a la discusión o anuncio relevante para que pueda leer cómo y por qué se tomó esta decisión.
Agrupar complementos más comunes también permite que más sitios aprovechen no tener que compilar su propio JS, reduciendo los tiempos de compilación y los costos de recursos.
Así que todavía no he tocado el botón de actualización porque uso algunos de los complementos que ahora están incluidos. No tengo miedo, sobreviví a la actualización de la base de datos hace unos meses.
¿Es mejor actualizar mi app.yml de la lista en el OP (respaldado primero, obvio) o recibiré un mensaje de error significativo en la interfaz de usuario que me dirá cuáles eliminar y detener para hacerlo?
Eso está respondido en el título del tema. Popular a menudo significa comúnmente instalado y utilizado. Agruparlos para Self Hipsters significa que no necesitas perder tiempo instalándolos. Muchos complementos y TC eventualmente se fusionaron con el programa principal.
El beneficio de tener estos como complementos permite un tiempo de desarrollo para probar las preferencias de los consumidores y desarrollarlos completamente.
Claro que habrá una variedad de comunidades que no usarán ninguno de los que se agruparon con el núcleo. Pero la métrica más grande probablemente muestra que estos son a menudo los que se instalan después de la configuración. Luego, por supuesto, también tienen las métricas de su alojamiento pago de complementos usados y no usados en el nivel base.
Me perdí 2 complementos antes de mi reconstrucción. Sin embargo, el registro de errores mejoró mucho para identificar esto fácilmente en comparación con antes, donde tenías que desplazarte y identificar el problema.
Creo que la indicación que mencionó David es o el error de reconstrucción o podría estar en tu página de complementos para la actualización web.
No te preocupes, no siempre es fácil ver una respuesta antes de plantear la pregunta.
Yo mismo actualicé mi app.yml
Usando comentarios, organicé el mío por proveedores de plugins para una clasificación más fácil. Dicho esto, todavía fue un poco doloroso. Creo que en una publicación anterior alguien publicó un método para verificar antes de reconstruir.
Para ser honesto, como este era el hilo de anuncios, vine aquí y comencé un comentario ya que la actualización falló y no recibí una notificación sobre tener que editar primero. Luego, una vez que eso se resolvió, edité la publicación. Pero si esta es la única discusión pública, gracias.
Puedo entender los pros, pero definitivamente hay contras. Así que creo que no todos los propietarios de foros de Discourse van a ser grandes fanáticos de los plugins. Así que hubiera sido bueno quizás ofrecerlo como una opción. Tal vez durante la actualización una sola indicación, o tal vez en el área de administración una configuración o notificación que te recuerde que establezcas tu preferencia antes de la próxima actualización.
¿Hay alguna página que enumere qué plugins se han incorporado por fecha? No me gusta actualizar a través del administrador web solo para que falle. Estoy en la versión 3.5.0.beta9-dev (04dbc622ab).
Quizás me perdí la página con las fechas/versiones en las que se han instalado las actualizaciones. Gracias.
La idea es probablemente que son los complementos más populares, y la mayoría de las personas ya están usando alguna combinación de ellos (como usted mismo). Realmente no es “bloat” porque no tienen casi ninguna huella, y no tiene que usar ninguno de ellos para nada. Esto es muy diferente a tener 20 programas que no quiero instalados en Windows, estos son interruptores de encendido/apagado (la mayoría de las personas no los verán, y usted como administrador los tendrá en una lista de otras 300 cosas que ya no está usando/cambiando) no es algo que surge constantemente / ocupa espacio real / está configurado para hacer cosas por defecto. Tener un programa de notas instalado por defecto que no quiero significa que terminaré teniendo dos. Tener un complemento que no quiero significa que simplemente hay una opción sentada en un panel
También es mucho más fácil tener interruptores de encendido/apagado que tener que buscar en un foro de terceros (o en infinitos githubs) algo que ni siquiera sabes que existe en primer lugar. Esta fue en realidad la primera vez que fui consciente de un puñado de estos.
Finalmente tuve tiempo de actualizar a 3.5.0.beta9-dev (df03ef6d05)
Tengo una instalación estándar autoalojada.
Edité mi app.yml para eliminar las líneas de plugins (según el consejo de Dan arriba) y luego procedí a iniciar el proceso de actualización. Tuve que actualizar el administrador de Docker antes que todo lo demás, como de costumbre, y eso fue normal. Una vez actualizado el administrador de Docker, me recibió un mensaje nuevo (para mí).
Ya había hecho una reconstrucción anteriormente, así que sabía cómo hacerlo y como putty todavía estaba abierto a mi servidor, no fue una inconveniencia, pero me sorprendió un poco no poder usar la interfaz de usuario para hacer la actualización. Solo publico esto como una advertencia para otros novatos autoalojados como yo. Aparte de eso, la actualización fue bien, todo funciona. Gracias equipo y comunidad.
Para los resueltos, votación de temas y plantillas, tienes razón en que los plugins en sí están habilitados. Pero esos plugins no hacen nada hasta que las funciones se habilitan para una categoría en particular.
Ojalá se preocuparan más por mantener la compatibilidad y no hacernos perder medio día cada vez que actualizamos nuestros sitios. Limpiar un poco su código no vale la pena romper los sitios de las personas y hacerles perder el tiempo.
Francamente, estoy empezando a buscar alternativas a Discourse porque estoy harto de que todo mi sitio se rompa cada pocos meses y tenga que averiguar cómo arreglarlo cuando nada de esto está en mi área de especialización.
Lamento escuchar tu frustración, aunque no estoy seguro de qué problemas encontraste específicamente con los plugins incluidos aquí.
Intentamos que las actualizaciones sean lo más fáciles y sencillas posible, pero con cambios tan grandes como este, a veces inevitablemente causan algunos inconvenientes. En este caso, agregamos salidas de error específicas sobre cómo modificar la configuración de tu sitio para que sea lo más simple posible de solucionar.
Un problema que creo que está en juego es que Discourse_docker no es muy bueno para saber cuándo se requiere una reconstrucción de la línea de comandos. Y eso hace que sea fácil romper tu sitio al hacer clic en actualizar en el panel de administración. (al menos eso es lo que creo que veo que la gente se queja)
Creo que solía ver commits que decían que hacían eso y creo que ya no los veo tanto. Yo mismo no uso discourse_docker (mucho?), así que no he prestado mucha atención.
Si este usuario hubiera ejecutado una reconstrucción y no la actualización desde la interfaz de usuario, podría haber hecho simplemente un
./launcher start app
Y esperar a lidiar con la actualización cuando fuera conveniente.
