Estoy explorando la posibilidad de crear un foro compartido para dos sitios web separados, mi blog y mi portafolio. El concepto es tener una única base de datos de foro que sirva a ambos sitios, permitiendo que los usuarios y temas se compartan entre las dos comunidades. Sin embargo, me gustaría que el foro tuviera un estilo diferente dependiendo del sitio que el usuario esté visitando, de modo que cada comunidad se sienta distinta mientras sigue siendo parte de un espacio compartido más grande.
Tengo experiencia en desarrollo web, aunque no he trabajado en un proyecto importante como este en mucho tiempo. Estoy dispuesto a volver a sumergirme y aprender lo que sea necesario para que esto funcione, pero agradecería orientación sobre si esto es factible con Discourse.
Específicamente, me pregunto:
¿Puede Discourse soportar temas o estilos distintos basados en el dominio o URL de referencia?
¿Es posible configurar Discourse para mostrar una marca personalizada (logotipos, colores, etc.) manteniendo una base de datos de usuarios y un grupo de temas compartidos?
¿Existen plugins o extensiones que puedan facilitar la implementación?
¿Algún consejo sobre los desafíos o limitaciones que debo considerar al seguir este tipo de configuración?
Este proyecto aún se encuentra en la fase conceptual y planeo comenzar a construir hacia finales de año. Quiero asegurarme de que Discourse sea la plataforma adecuada para esta visión antes de comprometerme.
¡Gracias de antemano por cualquier información, sugerencia o recurso que puedan proporcionar!
Todavía no está muy claro.
Entonces, ¿el dominio a apunta al foro y el dominio b apunta al mismo foro/foro diferente con la misma base de datos? Si es así, ¿tal vez un foro diferente con la misma base de datos? Entonces el estilo puede ser diferente.
Haciendo una búsqueda rápida aquí, no estoy seguro de si se podría hacer con demasiada facilidad.
Una ruta quizás más fácil podría ser usar un interruptor vinculado al grupo principal y tener 2 grupos que, al cambiar del grupo A al grupo B, cambien los temas y quizás utilicen algo como el componente Theme component Página de inicio personalizada para grupos? O quizás utilice Modern Category+group boxes instalados dos veces (usados en el tema air) con personalizaciones basadas en el tema/grupo principal.
Aunque no lo sé yo mismo. Me preguntaría si tener 2 instalaciones de Discourse podría arriesgarse a corromper la base de datos? Aunque algunos tienen sitios de staging, pero creo que el sitio de staging se copia de seguridad del principal de forma rutinaria?
Mi suposición es que puedes ejecutar varios motores (instalaciones de Discourse) sobre la misma base de datos (por lo que necesitas una base de datos separada). Solo ejecutaría 1 sidekiq, sin embargo. De lo contrario, dos de ellos empezarían a pelear por los trabajos. Aparte de eso, creo que Discourse es una aplicación sin estado, por lo que no debería importar cuántos estés ejecutando.
Ahora una pregunta a la raíz de todo el problema: ¿Por qué? ¿Y no va en contra de las reglas de SEO? Creo que a Google no le gusta si encuentra el mismo contenido en varios sitios.
En realidad, es posible que algunas cosas no funcionen como se espera; por ejemplo, las actualizaciones de la interfaz de usuario en tiempo real (si alguien actualiza un artículo para que se vuelva a renderizar mágicamente mientras lo lees). Creo que los dos sitios no se informarían mutuamente, por lo que necesitarías que el usuario actualice su navegador. Podría haber más. Como si cambias la configuración del sitio en un sitio, supongo que el otro sitio tampoco se daría cuenta y necesitarías reiniciar el otro.
Basándome en Scaling up and sidekiq, me parece que esto es realmente solucionable. Sidekiq parece manejarlo y el resto sería cuestión de configurar Redis correctamente.
Es un poco fuera de tema y no quiero desviar la conversación, pero me gustaría añadir mi simple apreciación.
Creo que estamos en una era de internet donde uno necesita pensar en el SEO o en sus usuarios.
Y no tengo ninguna duda de que Discourse autoalojado será utilizado por aquellos que eligen a sus usuarios.
Estaba buscando esta función porque tengo proyectos personales con la misma audiencia y objetivo. Multisite con SSO fue lo más cercano, pero no llegué a ninguna parte porque es lento y no es conveniente.
Discourse no es sin estado, y toda la información está en la base de datos. Así que si ejecutas múltiples instancias sobre una sola base de datos, automáticamente se verían iguales y los cambios en una se reflejarían inmediatamente en la otra.
Esto “simplemente” sería una cuestión de cambiar temas. Quizás aprovechar la lógica existente de vista previa de temas y hacer que un plugin solo mire el nombre de host en lugar del parámetro de URL.
Alojar el mismo foro bajo dos URL podría ser la parte más difícil aquí, especialmente con respecto al SEO. Te metería en todo tipo de problemas de contenido duplicado y URL canónicas.
¿Puedes aclarar eso? Sería muy interesante saber un poco más cómo funciona. Creo que tus dos frases se contradicen. Creo que reflejar todo es realmente lo que el OP pidió. Pero, ¿cómo podría suceder si la otra instancia no es notificada de un cambio realizado por la primera instancia? Está almacenado en la base de datos, sí, pero no hay notificación.
Entonces, ¿solo una base de datos = sin estado (stateless)? Cada vez que haces una solicitud, vuelves a preguntar a la base de datos; no hay estado en memoria. ¿O sí?
Por lo demás, me gusta mucho la idea de un plugin. Estoy de acuerdo en que este sería el camino a seguir y también sigo pensando que el SEO no es algo que se elige hacer, sino que de alguna manera se tiene que hacer para conseguir audiencia. La duplicación sería una forma de lograrlo. Incluso desde el punto de vista del usuario, podría ser sospechoso si veo algo que escribí en un sitio y quizás está enlazado en otro sitio del que no tenía idea, me sentiría realmente perturbado. La duplicación de contenido es típicamente un método utilizado por sitios de baja calidad. Por eso recibe una degradación en SEO. Pero este sería más un tema para la categoría Community.
Creo que aquí hay una confusión de definiciones. El código del lado del servidor de Discourse es (más o menos*) sin estado, pero toda la instancia de Discourse (cliente web, código del lado del servidor, Redis, archivos en caché, base de datos) no lo es.
La otra cara de la moneda es que, dado que el código del lado del servidor no tiene estado, esta configuración no puede lograr lo que OP quiere, ya que no hay dónde almacenar la información sobre qué URL y tema se deben servir. La configuración que describes es en realidad lo que sucede en una configuración de balanceo de carga donde hay múltiples contenedores web y una única instancia de base de datos/Redis. Es un solo sitio.
* Digo “más o menos” porque hay muchas capas de caché en varios lugares
Entiendo. ¿La URL del sitio principal también se almacena en la base de datos? ¿Entonces no es una cuestión de configuración de una instancia local? En ese caso, quedaría claro que ambas instancias intentarían servir lo mismo.
Y tienes razón en que la configuración de dos servidores todavía no ayuda a Discourse a elegir el tema correcto en absoluto.
Ahora recuerdo que también habría un problema con el contenido. Si pegas un enlace en Discourse, publica la URL completa en él. Por lo tanto, alguien que lea un tema escrito por el otro sitio sería dirigido a él al hacer clic en un enlace. Lo mismo ocurre con las cargas, ver Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
¿Otro problema podrían ser los correos electrónicos? ¿Desde qué dominio irían los correos electrónicos de notificación? Otro problema: los complementos sociales (Facebook, etc.) o el inicio de sesión de Google redirigirían a un sitio incorrecto (o tal vez rechazarían el inicio de sesión).
Viniendo de la nada, una solución mucho más simple sería tener una sola instancia con 2 categorías: una para cada uno de los sitios principales. Esto evitaría todos los problemas mencionados anteriormente.
Hay mucho margen para estilizar categorías y temas dentro de esa categoría mediante CSS simple usando la clase category-category_slug.
Si desea que uno u otro sea el “predeterminado” o el hogar para un conjunto de usuarios, entonces Custom Homepage for Groups sería la herramienta que necesita.
