En las próximas semanas, moveremos varios plugins populares de Discourse al repositorio principal. Esto significa que Discourse vendrá con un mayor número de plugins por defecto, y nos será más fácil mantenerlos todos probados y actualizados.
Todos estos plugins permanecerán deshabilitados por defecto, por lo que esto no tendrá ningún impacto visible en las comunidades existentes. Si utilizas un servicio de alojamiento gestionado como discourse.org, no necesitas hacer nada.
Comunidades autoalojadas
Si autoalojas Discourse y ya estás utilizando uno de estos plugins, se te pedirá que elimines la línea correspondiente de tu archivo app.yml antes de tu próxima reconstrucción.
Entorno de desarrollo
Si ya tienes uno de los plugins instalado localmente y luego descargas la última versión del núcleo de Discourse, ocurrirá una de dos cosas.
Si utilizas enlaces simbólicos para tus plugins, obtendrás un error durante git pull. Para resolver el problema, elimina el enlace simbólico y luego ejecuta git pull de nuevo.
Si clonas los plugins directamente, el git pull del núcleo tendrá éxito, pero tendrás algunos ‘cambios sin staging’ sorprendentes causados por los repositorios git anidados. La mejor manera de proceder es eliminar el directorio afectado y luego restaurarlo desde main. Por ejemplo:
Gracias. Con mi escaso conocimiento de desarrollo y programación, aún me gustaría hacerle una pregunta. ¿Pueden estos complementos, que originalmente son componentes destinados a ser añadidos a una instalación básica, algún día perder su carácter de complemento y convertirse en una parte completa de una instalación básica, sin ser llamados complementos en absoluto?
Es posible, sí. En particular, es muy probable que los plugins de autenticación (por ejemplo, apple-auth) se incorporen al núcleo, al igual que nuestros otros métodos de autenticación integrados (por ejemplo, Google, Facebook, etc.).
Movimiento interesante que impulsa aún más el discurso por defecto y facilita nuevas instalaciones.
Una pregunta con respecto a:
se le pedirá que elimine la línea correspondiente de su archivo app.yml antes de su próxima reconstrucción.
¿También habrá un aviso o un mensaje de advertencia antes/cuando haga clic en el botón de actualización desde la página de actualización de administración?
Si recuerdo bien por mi experiencia, primero solo podrás actualizar docker. Una vez que hayas actualizado docker, se te mostrará un mensaje en la interfaz de usuario de actualización explicando que tienes que actualizar a través de la línea de comandos y cómo hacerlo.
Luego, cuando actualices en la línea de comandos, verás la PISTA para cada plugin que necesites eliminar de app.yml como se explica en la primera publicación anterior.
Esta es una buena actualización, pero ¿era realmente necesario? Dar un fallo de reconstrucción me parece un poco duro… una advertencia de interfaz de usuario o una actualización automática (o simplemente ignorarlas por completo) habría sido mejor que ponerme una pistola en la cabeza y decir “elimínalas ahora”.
Esto me pilló desprevenido la semana pasada cuando intenté actualizar a través de la línea de comandos y falló (plugin de reacciones).
Me pilló desprevenido de nuevo cuando mi actualización de línea de comandos volvió a fallar esta mañana (plugin de explorador de datos).
Agradecería mucho una advertencia en la línea de comandos antes de que comience el proceso de actualización y luego falle inevitablemente.
Dos veces en dos semanas mis actualizaciones han fallado y esto ha significado que mi Discourse ha estado fuera de servicio durante el tiempo que me lleva depurar el problema, editar configuraciones, volver a intentarlo, etc., todo mientras estoy en un estado leve de pánico porque todo está roto.
Me pregunto si tener todos estos plugins incluidos en el núcleo hinchará los foros. Es decir, probablemente habrá algunos plugins que los administradores no querrán en su foro (por ejemplo, Discourse AI), pero no tendrán más remedio que tenerlo añadido. Se puede desactivar, por supuesto, pero me pregunto si los archivos adicionales y demás ralentizarán los foros.
En el lado del cliente, Discourse no sirve ningún activo de javascript para los plugins deshabilitados, por lo que no habrá ningún impacto allí.
En el lado del servidor, para los plugins implementados correctamente (que todos estos lo son), las personalizaciones de los plugins se omiten cuando están deshabilitados. Así que sí, técnicamente podría haber una ligera sobrecarga para verificar el estado habilitado/deshabilitado, pero debería ser minúscula.
Los plugins que estamos fusionando aquí son los que ejecutamos en cada instancia de Discourse en nuestro hosting discourse.org. Por lo tanto, todos están muy bien probados a escala.
¿Hay alguna razón por la que estés haciendo todo esto de golpe poco antes del lanzamiento? Para los traductores que hacen esto en su tiempo libre, 3.000 cadenas adicionales en dos semanas es mucho. E incluso en idiomas donde los plugins se habían traducido previamente, los 3.000 textos tienen que ser revisados de nuevo. De vez en cuando, 300 serían probablemente más manejables que 3.000.
Para las comunidades autoalojadas que ya ejecutan uno o más de estos complementos, ¿perderán los complementos los datos de configuración cuando se eliminen de app.yml y se incorporen al núcleo?
Tengo el complemento de IA configurado exactamente como lo quiero; si necesito reconfigurarlo (o al menos anotar las opciones de configuración para poder volver a agregarlas), sería bueno saberlo ahora.
Hemos estado intentando que esto sea lo más fluido posible para los traductores utilizando la memoria de traducción en Crowdin, para que las traducciones no tengan que rehacerse desde cero. Pero aun así, estoy de acuerdo, hay mucho que revisar.
Me pregunto si hay algo más que podamos automatizar aquí, por ejemplo, tal vez podamos “aprobar automáticamente” cualquier cadena de estos complementos, en lugar de requerir una revisión :ojos:
