Habiendo sido afectado por el problema de “fallo en la reconstrucción del plugin” al principio de mi autoalojamiento de Discourse, aprecio el deseo de agrupar versiones conocidas y buenas en el núcleo. Y potencialmente ofrecer una selección más rica de características.
Una organización centrada en el cliente podría haber realizado una encuesta sobre la dirección del plugin principal, o al menos sobre el momento. Quizás me lo perdí. Como proveedor de herramientas de TI para mis clientes (es decir, usuarios finales) que intentan hacer un trabajo real con TI, he visto muchos productos revisados hacia una complejidad excesiva y un reemplazo final. Ahora tendremos autoalojadores que eliminarán los plugins que no necesitan. Entiendo esto y puedo unirme a ese club. En mi experiencia, el código adicional aumenta la complejidad de la integración, el riesgo de errores de configuración y la superficie de ataque. Pero tarde o temprano, eliminar algo que el desarrollador de la aplicación asume que estará allí, también romperá algo.
Hubiera preferido mucho más que los esfuerzos de los jedi de Discourse se hubieran centrado en trabajar en un método robusto, mantenido y con scripts para habilitar el almacenamiento en la nube de imágenes, incluida la integración de CDN. La integración de correo electrónico SMTP es trivial en comparación, y eso se ha roto con los cambios en MailGun y otros, causando problemas a los sitios autoalojados.
De hecho, desaconsejaría encarecidamente el uso de rm -rf en estos plugins. Como dices, existen riesgos en torno a interdependencias inesperadas en el futuro. Pero además, crearás una diferencia en el repositorio git principal, lo que significa que las actualizaciones de la interfaz de usuario a través de docker_manager casi con certeza fallarán.
Por supuesto, dejar estos plugins en su estado predeterminado de ‘deshabilitado’ está totalmente soportado y garantizará que no tengan ningún impacto medible en el rendimiento.
Para quienes auto-hospedan o quienes, como yo, brindan servicios de hospedaje para clientes, aquí hay un grep simple que listará si alguno de los nuevos plugins incluidos ya está en tu containers/app.yml
Necesita ejecutarse como root y mostrará cualquier línea que deba eliminarse manualmente de la sección de plugins de app.yml antes de que la reconstruyas.
¿Podrías considerar cambiarlo para que haga referencia a containers.*.yml para que también ayude a cualquiera que haya hecho una instalación estándar de dos contenedores donde estarían en web-only? Realmente no quieres que estén en ninguna de tus definiciones de contenedor, después de todo.
@david ¿Considerarías añadir eso a la publicación principal y mantenerlo una vez que integres cakeday?
Agradece a ChatGPT que lo elaboró exactamente correctamente de una sola vez a partir de esta indicación:
Por favor, extrae las URL de GitHub de cada uno de los complementos mencionados en esta publicación https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
Compílalos en una lista y crea un comando de Unix que me diga si alguno de estos complementos ya se menciona en un ‘git clone’ en el archivo containers/app.yml de ese Discourse.
En apariencia, para mí, esto sí suena como algo razonable a considerar hacer en algún momento – tener una forma más declarativa de definir qué plugins se cargan o no en el momento del arranque, incluso si la fuente todavía está allí en el disco.
Dicho esto, no sé cuál sería la viabilidad o el esfuerzo para hacer eso.
Es ciertamente posible. Pero añade complejidad, una cosa más que soportar/mantener. Y solo sería útil en entornos de un solo inquilino (es decir, no en entornos de alojamiento compartido, donde diferentes inquilinos quieren diferentes plugins).
En todo caso, creo que sería más beneficioso dedicar tiempo a mejorar la experiencia de usuario y el rendimiento de los plugins ‘deshabilitados’ (lo cual ya hemos empezado a hacer desde esta gran fusión en el núcleo).
tampoco he intentado eliminar los complementos, porque siento que comprometería mis informes de errores para meta, incluso el intento de una instalación de alojamiento compartido
Uf, esa fue una actualización complicada. Identificar el problema en el desorden del registro de reconstrucción no es nada trivial para empezar. Lo encontré, pasé por alto otro plugin que debía eliminar de nuestra configuración dos veces, por lo tanto, el tercer intento de reconstrucción finalmente superó esa parte. Hubiera sido realmente útil verificar y advertir desde el principio que la configuración necesita ajustarse. discourse-doctor verifica (demasiado simple, pero puede tomarse como punto de partida) los plugins en la configuración, por lo que se puede usar como base. Probablemente ya sea demasiado tarde, 3 semanas después, en fin…
Pero eso no fue todo, también nos encontramos con errores de db:migrate. Lo intenté 2 veces, luego ejecuté discourse-doctor, que también ejecutó la reconstrucción y, extrañamente, tuvo éxito. Revisé su código y no hace absolutamente nada, y llama a la reconstrucción de la misma manera que nosotros. Por lo tanto, parece que db:migrate tuvo éxito en el tercer intento por alguna razón. Leí en el hilo que la gran cantidad de plugins agregados añaden dependencias, que pueden entrar en conflicto/ser más antiguas que las que se usaban anteriormente. Por suerte, no necesitamos agregar un paso de eliminación manual de plugins, ajuste de dependencias o cambio de base de datos, como otros parecen haber necesitado. ¿Se espera de alguna manera que ejecutar db:migrate varias veces finalmente tenga éxito? Solo puedo esperar que nada esté roto…
Se instaló antes, simplemente lo omitimos de la interfaz de usuario junto con el resto de los complementos empaquetados de antes. Nuestra interfaz de usuario se mejoró para mostrar correctamente todo lo que existe. (Teníamos una serie de omisiones, incluido Chat, que estaba oculto mediante CSS)
Ya he observado un aumento en la velocidad del equipo de desarrollo interno en el muy corto tiempo que esto ha estado en vigor. Está conduciendo a un producto más estable, algo de lo que estoy muy contento.
No hay planes de retroceder aquí. Necesitas adaptarte al nuevo mundo.
En mi opinión, si algo se rompe porque un plugin no está instalado, entonces eso es un error. El núcleo no debería depender de plugins. Los plugins en sí mismos deberían enumerar claramente sus requisitos en sus respectivas páginas.
Pero sí, esto hará que la versión autoalojada sea aún menos estable en el futuro, ya que serán los autoalojadores quienes tropiecen con estos problemas. Entre esto y el hilo bifurcado, realmente no tengo la impresión de que la estabilidad de los autoalojadores sea una alta prioridad para el equipo.
No lo habíamos pensado de antemano, así que es posible que falten algunas aprobaciones. Pero logramos transferir una buena parte de ellas de los proyectos de plugins en Crowdin al núcleo. Lo haremos mejor la próxima vez, ya que ahora tenemos las herramientas para transferir aprobaciones entre proyectos.
No, no lo comprobamos de antemano, pero lo comprobé después. Ninguno de los plugins tenía comentarios sin respuesta en Crowdin. Tenemos una herramienta interna que almacena todos los comentarios que se publican en nuestros plugins de Crowdin. Incluso podríamos usarla para volver a publicar comentarios faltantes en Crowdin, por ejemplo, cuando Crowdin elimina comentarios porque se actualizó la cadena de origen. Simplemente no ha sido una prioridad implementarlo.
De acuerdo. Quizás una opción para listar los plugins principales habilitados instalados. En lugar de simplemente mostrar todos los plugins. Definitivamente, más opciones de filtrado son mejores.
Estoy de acuerdo con el sentimiento. En mi opinión, la verdadera desconexión es mantenerlos listados como plugins.
Una vez fusionado, debería moverse a algo con marca como “Características principales”, ya que los plugins se ven como componentes opcionales que se pueden instalar. En lugar de ser parte del programa principal. Por lo tanto, en mi opinión, es un nombre inapropiado mantenerlos listados como plugins cuando la intención no es desinstalarlos.
Similar a los TC que se fusionaron en el núcleo, como “burbujas personales”, no se enumeran en Componentes de tema. Es cierto que en ese caso particular no se puede deshabilitar el TC anterior. Si quisieras volver a lo que era antes, necesitarías crear un TC para deshacer los cambios
Definitivamente estoy de acuerdo con opciones de filtrado adicionales. También tener una para plugins deshabilitados.
Sin embargo, después de pensar más y leer más publicaciones. Si los plugins se fusionan con el núcleo. Realmente tal vez ya no deberían llamarse plugins y no listarse en Plugins. Pero tal vez algo como Características Principales o Características Opcionales. Dado que estos ya no están realmente destinados a ser desinstalables.
No hay ninguna razón por la que un software de foro bien diseñado deba requerir código publicitario para funcionar.
Si Discourse decide incorporar anti-características, lo único que va a obligar a la gente a hacer es bifurcar Discourse o migrar a otra cosa. Aquellos de nosotros a los que no nos gusta la tecnología / cosas de publicidad sentimos muy firmemente esto. Discourse NO nos lo impondrá, por mucho que se intente. (Ubuntu intentó esto con nosotros y ahora mi repositorio con más estrellas es algo que elimina los anuncios ;))
No estoy seguro de entender. Si por código de publicidad te refieres a plugins que se fusionan en el producto principal en lugar de seguir siendo complementos/instalaciones opcionales. Si retrocedemos, encontrarás que una variedad de “código de publicidad” se fusionó en el núcleo.
Puedo ver desde la perspectiva del equipo de desarrollo que muchos de sus plugins pueden haber comenzado como plugins para permitir pruebas más flexibles antes de integrarlos en el programa principal.
Puedo apreciar que, como en cualquier software, a menudo hay funciones que la gente podría no usar y optar por deshabilitarlas, y depende de encontrar formas de desinstalar funciones.
Si bien admito que hay muchos plugins fusionados recientemente que probablemente no usaría. Pero tener una simple opción de deshabilitar y filtrarlos es algo bueno para todos.
Entiendo que, en parte, como afirma el equipo, la intención es facilitar las cosas con complementos para autoalojados.
Ahora, en mi opinión, la interfaz de administración debería ser más personalizable, como lo fue una vez. Ya que esto también puede ayudar a las personas que migran desde otra plataforma al poder cargar una administración allí que tenga un diseño similar al de la plataforma de la que provienen. Muy parecido a cómo Linux hace esto imitando otros sistemas operativos. Pero ese es otro tema.
Puedo apreciar la sensación de que Discourse podría estar empezando a dirigirse hacia el bloatware. Los reactores demostraron lo mucho más ligero que podría ser Windows NT.
