He notado que la gente suele intentar primero el modo seguro cuando algo falla y están usando personalizaciones de terceros. Tiene sentido. No sabes de dónde proviene el problema.
Sin embargo, el modo seguro solo desactiva JavaScript. Si hay algún código del lado del servidor, la solución inmediata suele ser descomentar todos los complementos en el archivo app.yml. Eso está bien, pero requiere una reconstrucción y es relativamente “técnico”. Si eres un usuario no técnico, comentar cosas en el app.yml no es algo que tomes a la ligera.
Me pregunto sobre la viabilidad de una PR que añada la desactivación de complementos del lado del servidor en el modo seguro. Estoy pensando en algo así en el controlador de modo seguro.
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
Sí, el mismo efecto podría lograrse si el usuario revisa la configuración de su sitio y desactiva los complementos de esa manera, pero creo que los usuarios rara vez lo hacen realmente.
El modo seguro actual solo afecta a la página actual y desaparece al abrir una nueva pestaña o al recargar. Por lo tanto, es completamente seguro para pruebas.
Tu propuesta cambiaría su significado a la activación persistente de una configuración que afectaría a todo el sitio. Eso también implica que debe restringirse a los administradores.
Entiendo tu propuesta, pero supone un cambio significativo en el comportamiento.
Creo que el punto clave es que los administradores de sitios no técnicos buscan una solución para que su sitio funcione cuando está roto. Un “modo seguro” a menudo se percibe como una solución para eso (correcta o incorrectamente). Quizás una forma de lograr esto sería tener controles adicionales de modo seguro para administradores.
Podrías agregar un botón grande en la ruta /admin/plugins para desactivar automáticamente todos los plugins de la misma manera, sin embargo, me pregunto si tendría el mismo efecto. Quizás sí lo tendría.
También me atrae esta idea porque es bastante factible dentro de la arquitectura actual de plugins de Discourse.
Por lo general, lo que rompe los plugins son cambios incompatibles en el núcleo; a menudo, el sistema ni siquiera arranca si incluyes un plugin problemático o durante el arranque.
Una función para desactivar todos los plugins tendría que reiniciar la aplicación de alguna manera para funcionar correctamente.
Creo que estaría abierto a un cambio en el plugin de gestor de Docker que te permita desactivar/activar plugins fácilmente moviendo archivos dentro y fuera del directorio de plugins y reiniciando la aplicación; esto podría acelerar la depuración.
Sin embargo, noto que un número considerable de errores provienen de código envuelto en la API del plugin del lado del servidor, lo cual sería manejado por esto (¿creo?).
Actualmente, el ‘modo seguro’ (o algo similar) tampoco es una solución completa para los problemas de ruptura. Agregar una desactivación automática de plugins lo convertiría en una solución ligeramente mejor, reduciendo la cantidad de casos en los que se requiere un reinicio completo o un cambio de configuración, y reflejando mejor cómo lo ven los administradores de sitios no técnicos.
Supongo que estoy buscando pasos incrementales y relativamente sencillos. Quizás el cambio en el gestor de Docker sea igualmente directo desde una perspectiva técnica.
Sí, si es posible algún día, sería muy bueno tener un solo booleano “desactivar todos los complementos” en la configuración de administración, que funcione sin necesidad de reconstruir ningún contenedor. Sin embargo, al no ser un desarrollador de Discourse (teniendo solo un año de desarrollo de aplicaciones en node.js y vuejs), mi instinto me dice que este no es un cambio sencillo y sería una modificación muy grande en la arquitectura.
Nuestro foro heredado de LAMP tenía esta función y no podemos contar las veces que usamos este booleano para identificar rápidamente si un error estaba relacionado con los complementos. Sin embargo, la arquitectura del software es tan diferente que ni siquiera es útil compararlos.
Personalmente, confío en que el equipo de Discourse encontrará una solución. Muchos usuarios dependen de los complementos y con el tiempo surgirán más desafíos.
Un factor importante para mí es que esta función sería 100% para quienes hacen autoalojamiento; no quiero realmente tener que mantener un modo seguro para complementos en el núcleo, ya que definitivamente no es algo que usaríamos. Coordinar un reinicio en 5 clústeres es difícil.
El gestor de Docker es el vehículo adecuado aquí: ya soporta el reinicio de la aplicación, algo necesario para que tu propuesta funcione, y puede realizar todo lo necesario sin cambios en el núcleo de Discourse.