Estou explorando a possibilidade de criar um fórum compartilhado para dois sites separados, meu blog e meu portfólio. O conceito é ter um único banco de dados de fórum que sirva a ambos os sites, permitindo que usuários e tópicos sejam compartilhados entre as duas comunidades. No entanto, eu gostaria que o fórum fosse estilizado de forma diferente dependendo do site que o usuário está visitando, para que cada comunidade se sinta distinta, mas ainda assim faça parte de um espaço compartilhado maior.
Tenho experiência em desenvolvimento web, embora não trabalhe em um projeto grande como este há algum tempo. Estou disposto a mergulhar novamente e aprender o que for necessário para fazer isso funcionar, mas agradeceria orientação sobre se isso é viável com o Discourse.
Especificamente, estou me perguntando:
O Discourse pode suportar temas ou estilos distintos com base no domínio ou URL de referência?
É possível configurar o Discourse para exibir branding personalizado (logos, cores, etc.) enquanto mantém um banco de dados de usuários e um pool de tópicos compartilhados?
Existem plugins ou extensões que possam facilitar a implementação disso?
Algum conselho sobre desafios ou limitações que devo considerar ao buscar este tipo de configuração?
Este projeto ainda está na fase conceitual e planejo começar a construir no final do ano. Quero garantir que o Discourse seja a plataforma certa para essa visão antes de me comprometer.
Agradeço antecipadamente por quaisquer insights, sugestões ou recursos que possam fornecer!
Correto.
Ambos os domínios compartilham um fórum, residindo em um banco de dados. Apenas a personalização visual é diferente, se é que isso é possível.
Ainda não está muito claro.
Então o domínio a aponta para o fórum, e o domínio b aponta para o mesmo fórum/fórum diferente com o mesmo banco de dados? Se sim, talvez um fórum diferente com o mesmo banco de dados? Então o estilo pode ser diferente.
Fazendo uma busca rápida aqui, não tenho certeza se isso seria ou poderia ser feito com muita facilidade.
Talvez uma rota mais fácil seja usar um alternador vinculado ao grupo primário e ter 2 grupos que, ao alternar do grupo A para o grupo B, mudam os temas e talvez usem algo como o componente Theme component de página inicial personalizada para grupos? Ou talvez use caixas de Categoria Moderna + grupo instaladas duas vezes (usadas no tema air) com personalizações baseadas no tema/grupo primário
Embora eu mesmo não saiba. Eu me perguntaria se ter 2 instalações do Discourse poderia arriscar corromper o banco de dados? Embora alguns tenham sites de staging, mas acho que o site de staging é regularmente copiado do principal?
Minha suposição é que você pode executar vários motores (instalações do Discourse) sobre o mesmo banco de dados (então você precisa de um banco de dados separado). Eu executaria apenas 1 sidekiq, embora. Caso contrário, dois deles começariam a brigar pelos trabalhos. Fora isso, acho que o Discourse é um aplicativo sem estado, então não deveria importar quantos deles você está executando.
Agora uma pergunta para a raiz de todo o problema: Por quê? E isso não é contra as regras de SEO? Acho que o Google não gostou se encontrou o mesmo conteúdo em vários sites.
Na verdade, talvez algumas coisas não funcionem como esperado – por exemplo, atualizações de UI em tempo real (se alguém atualizasse um artigo para que ele fosse renderizado magicamente enquanto você está lendo). Acho que os dois sites não se comunicariam, então você precisaria depender do usuário atualizando o navegador. Pode haver mais. Como se você mudasse as configurações do site em um site, acho que o outro site também não notaria e você precisaria reiniciar o outro.
Com base em Scaling up and sidekiq, parece-me que isso é realmente solucionável. O Sidekiq parece lidar com isso e o resto seria uma questão de configurar o Redis corretamente.
É um pouco fora do tópico, e eu não quero desviar a conversa, mas gostaria de adicionar minha simples apreciação.
Eu acho que estamos em uma era da internet onde é preciso pensar em SEO ou em seus usuários.
E não tenho dúvidas de que o Discourse auto-hospedado será usado por aqueles que escolhem seus usuários.
Eu estava procurando por este recurso porque tenho projetos pessoais com o mesmo público e alvo. Multisite com SSO foi o mais próximo, mas não cheguei a lugar nenhum porque é lento e não é conveniente.
O Discourse não é sem estado, e todas as informações estão no banco de dados. Portanto, se você executar várias instâncias em cima de um único banco de dados, elas automaticamente parecerão as mesmas e as alterações em uma se refletirão imediatamente na outra.
Isso “apenas” seria uma questão de trocar temas. Talvez alavancar a lógica existente de pré-visualização de temas e ter um plugin que apenas olhe para o nome do host em vez do parâmetro de URL.
Hospedar o mesmo fórum sob dois URLs pode ser a parte mais difícil aqui, especialmente em relação ao SEO. Isso o colocaria em todos os tipos de problemas de conteúdo duplicado e URL canônico.
Você pode esclarecer isso? Seria realmente interessante saber um pouco mais sobre como isso funciona. Acho que suas duas frases se contradizem? Acho que refletir tudo é realmente o que o OP pediu. Mas como isso poderia acontecer se a outra instância não for notificada sobre uma alteração feita pela primeira instância? Está armazenado no banco de dados, sim, mas não há notificação.
Então, apenas um db = stateless. Toda vez que você faz uma solicitação, ele pergunta ao banco de dados novamente - não há estado na memória. Ou há?
Caso contrário, eu realmente gosto da ideia de um plugin. Concordo que esse seria o caminho a seguir e também ainda acho que SEO não é algo que você escolhe fazer, mas de alguma forma tem que fazer para conseguir público. A duplicação seria uma forma de realmente cortá-la. Mesmo do ponto de vista do usuário, pode ser suspeito se eu vir algo que escrevi em um site, talvez vinculado em outro site sobre o qual eu não tinha ideia, eu ficaria realmente perturbado. A duplicação de conteúdo é tipicamente um método usado por sites de baixa qualidade. É por isso que ele recebe um rebaixamento de SEO. Mas isso seria mais um tópico para a categoria Community.
Acho que estamos em uma confusão de definições aqui. O código do lado do servidor do Discourse é (meio que*) sem estado, mas toda a instância do Discourse (cliente web, código do lado do servidor, Redis, arquivos em cache, banco de dados) não é.
O outro lado dessa moeda é que - dado que o código do lado do servidor é sem estado - essa configuração não pode realizar o que o OP quer, pois não há onde armazenar as informações de qual URL e tema devem ser servidos. A configuração que você está descrevendo é, na verdade, o que acontece em uma configuração de balanceamento de carga onde existem vários contêineres web e uma única instância de banco de dados/Redis. É um único site.
* Estou dizendo “meio que” porque existem muitas camadas de cache em vários lugares
Entendi. O URL do site principal também é armazenado no banco de dados? Então não é uma questão de configuração de instância local? Nesse caso, ficaria claro que ambas as instâncias ainda tentariam servir a mesma coisa.
E você está certo de que a configuração de dois servidores ainda não ajuda o Discourse a escolher o tema certo.
Agora me lembro que haveria um problema com o conteúdo também. Se você colar um link no Discourse, ele postará o URL inteiro nele. Assim, alguém lendo um tópico criado pelo outro site seria direcionado a ele ao clicar em um link. O mesmo com uploads, veja Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
Outro problema poderiam ser os e-mails? De qual domínio iriam os e-mails de notificação? Outro problema – plugins sociais (Facebook etc.) ou login do Google redirecionariam para um site errado (ou talvez recusem o login).
Vindo de um lugar inesperado, uma solução muito mais simples seria ter uma única instância com 2 categorias - uma para cada um dos sites pais. Isso contornaria todos os problemas mencionados acima.
Há muito espaço para estilizar categorias e tópicos dentro dessa categoria por meio de CSS simples usando a classe category-category_slug.
Se você quiser tornar um ou outro o “padrão” ou a página inicial para um conjunto de usuários, então Custom Homepage for Groups seria a ferramenta que você precisa.
