Hola, ¿es normal que el sitio esté fuera de línea al instalar/actualizar temas y complementos?
1 me gusta
Es normal que el sitio esté inactivo cuando se reconstruye.
Las soluciones son usar una instalación de dos contenedores, lo que le permite construir un nuevo contenedor, por lo que el tiempo de inactividad es de menos de un minuto, o ingeniárselas para que se muestre una página de “volveremos enseguida” mientras el sitio está inactivo, lo que no cambia el tiempo de inactividad, pero entonces todos saben que usted es consciente de que su sitio está inactivo.
Todo el mundo piensa que al menos una de estas soluciones es demasiado difícil y que no vale la pena el problema.
4 Me gusta
Solo para añadir, a diferencia de los plugins, instalar o actualizar temas y componentes de temas no requeriría tiempo de inactividad. 
4 Me gusta
¿Hay alguna documentación sobre el método que mencionó? Además, parece irónico considerando que es muy adecuado para SEO en términos de discurso, pero hay una interrupción durante la carga y los bots de Google no pueden rastrear el sitio.
¿Cuántas veces espera instalar un nuevo complemento? Esto suele ser algo muy poco frecuente.
Puede actualizar los complementos en línea con una interrupción mínima del servicio a medida que los contenedores se intercambian.
2 Me gusta
Gracias por las respuestas. 
1 me gusta
Echa un vistazo a Add an offline page to display when Discourse is rebuilding or starting up cuando te sientas valiente.
2 Me gusta
Hola 
No estoy seguro y quizás me equivoque (aún no lo he intentado), pero ¿esto es ahora una funcionalidad principal? Hay una nueva plantilla hace unos meses en discourse/templates llamada offline-page.template.yml y dentro de ella activa GitHub - discourse/discourse-offline-page: offline page for discourse. Que es el sitio HTML estático durante la carga de Discourse. También hay una PR al respecto en discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
3 Me gusta
Parece que eso solo afectaría a la mitad. Aparecería al iniciar, pero no al reconstruir, si entiendo bien las reconstrucciones:
Añade una plantilla para obtener y servir archivos HTML estáticos de GitHub - discourse/discourse-offline-page: offline page for discourse cuando nginx esté disponible, pero rails no.
^ El PR de github
2 Me gusta
Pero un paso en la dirección correcta, ¡gracias @Don (y @featheredtoast ! )
Sí @Firepup650 Me preguntaba por qué no lo había visto, ¡y creo que has respondido por qué!
¡Tengo algunos buenos 
aquí! 
¿Me pregunto si este es un paso previo a una configuración permanente estándar de dos contenedores, donde un contenedor nginx se construye por separado?!??! 
2 Me gusta
Me atrapaste: hay un movimiento en curso para hacer que las páginas sin conexión sean más accesibles. Las confirmaciones y los repositorios mencionados son la base para que esté disponible, pero aún no está implementado.
5 Me gusta
Por alguna razón, ninguno de mis usuarios ve eso en reconstrucción. Bueno, al menos en el chat, y es por eso que ha habido algunos incidentes en los que un usuario ha perdido mensajes escritos.
Mi opinión es que la situación en la que no informamos en absoluto sobre el tiempo de inactividad para los usuarios que ya han iniciado sesión es el mayor problema de UX único en Discourse. Claro, puedo entender las explicaciones de dónde proviene por la naturaleza misma de esta aplicación, y los desarrolladores se han pintado solos en un rincón desde el principio (situaciones similares a las de los borradores y algunas otras cosas), pero eso no borra el problema en sí.
Tenemos algunas soluciones alternativas. Usar Nginx como proxy inverso delante de Discourse mostrando una página de error ajustada es una. Y cuando un administrador tiene problemas, la respuesta será “solo admitimos la estándar”. Esa fue la razón real por la que abandoné esa.
Dos contenedores diferentes son una solución. O al menos mantiene el tiempo de inactividad muy corto. Hay demasiadas advertencias sobre eso, así que tengo un poco de miedo de tomar ese camino.
O podemos actualizar solo a veces, informar a los usuarios antes de que suceda y cerrar el acceso público. Sí, esa es una solución, pero… ahora es el año 2024 y solo el sistema bancario lo usa en mi entorno 
Usar un servidor de staging es algo que se debería hacer. Bueno, esa es una solución a nivel corporativo, costosa y bastante difícil cuando se hace bien, y ama a su propio equipo de TI.
Así que los nuevos planes filtrados 
son una mejora real. Bueno, si necesita contenedores separados, entonces es hora de sumergirse en lo profundo, supongo.
1 me gusta
Es exactamente lo mismo, excepto que rara vez también necesitas reconstruir el contenedor de datos.
1 me gusta
Pero el tiempo de inactividad es mucho más corto que el tipo de 20 minutos, ¿no?
1 me gusta
El chat puede tener cosas diferentes a la visualización normal del sitio, ya que creo que es un acceso más en tiempo real en comparación con la posibilidad de almacenar páginas en caché.
De acuerdo. El mantenimiento anunciado y planificado, en mi opinión, es mejor como en los viejos tiempos de los BBS de acceso telefónico basados en DOS. Había una opción para tener un mensaje del sistema advirtiendo que el apagado de mantenimiento planificado se acercaba y desconectaría a los usuarios en el momento designado. En aquellos días, solía ser para hacer paquetes de correo entre BBS en red.
1 me gusta
Sí. El tiempo de inactividad suele ser inferior a un minuto, pero necesitarás suficiente RAM o espacio de intercambio para reconstruir un contenedor mientras el otro se compila.
1 me gusta