I’m exploring the possibility of creating a shared forum for two separate websites, my blog and my portfolio. The concept is to have one forum database that serves both sites, allowing users and topics to be shared across the two communities. However, I’d like the forum to be styled differently depending on which site the user is visiting, so each community feels distinct while still being part of the larger shared space.
I have a background in web development, though I haven’t worked on a major project like this in a while. I’m willing to dive back in and learn what’s needed to make this work, but I’d appreciate guidance on whether this is feasible with Discourse.
Specifically, I’m wondering:
Can Discourse support distinct themes or styles based on the referring domain or URL?
Is it possible to configure Discourse to display custom branding (logos, colors, etc.) while maintaining a shared user database and topic pool?
Are there plugins or extensions that might make this easier to implement?
Any advice on challenges or limitations I should consider when pursuing this type of setup?
This project is still in the conceptual phase, and I’m planning to begin building towards the end of the year. I want to ensure Discourse is the right platform for this vision before committing.
Thanks in advance for any insights, suggestions, or resources you can provide!
I’m still not too clear.
So domain a points to the forum, and domain b points to the same forum/different forum with same database? If so, maybe a different forum with the same database? Then the style can be different.
여기서 빠르게 검색해 보았지만, 쉽게 가능할지 혹은 실제로 가능할지 확신이 서지 않습니다.
더 쉬운 방법으로는 기본 그룹에 연결된 토글을 사용하고, 그룹 A에서 그룹 B로 전환할 때 테마를 변경하도록 하는 방식이 있을 수 있습니다. 또한 그룹별 Customization > Theme component 커스텀 홈 페이지를 사용하는 것도 방법입니다. 아니면 air 테마에서 사용된 Modern Category+group 박스를 두 번 설치하고, 테마/기본 그룹에 따라 커스터마이징을 적용하는 방식도 고려해 볼 수 있습니다.
저는 직접 알지 못하지만, discourse를 두 개 설치하면 데이터베이스가 손상될 위험이 있는 것 같기도 합니다. 물론 스테이징 사이트를 운영하는 경우가 있지만, 스테이징 사이트는 메인 사이트에서 정기적으로 백업되는 것 같기도 합니다.
My guess is that you can run multiple engines (Discourse installations) on top of the same database (so you need a separate database). I would only run 1 sidekiq, though. Otherwise two of them would start fighting for the jobs. Other than that I think Discourse is a stateless app, so it should not matter how many of them you are running.
Now a question to the root of the whole issue: Why? And is it not against SEO rules? I think Google disliked if it found the same content on multiple sites.
Actually maybe some things might not work as expected – e.g. real time UI updates (if someone updated an article so that it magically re-renders while you are reading). I think the two sites would not tell each other so you would need to depend on the user refreshing their browser. There might be more. Like if you change the site settings on one site, I guess the other site would also not notice and you might need to restart the other one.
Based on Scaling up and sidekiq it seems to me that this is actually solvable. Sidekiq seems to handle it and the rest would be a matter of configuring Redis correctly.
It’s a little bit off-topic, and I don’t want to deviate the conversation, but I’d like to add my simple appreciation.
I think we are in an internet era where one needs to think about SEO or their users.
And I have no doubt that self-hosted Discourse will be used by those who choose their users.
I was looking for this feature because I have personal projects with the same audience and target. Multisite with SSO was the closest but I ending nowhere because it’s slow and not convenient.
Discourse is not stateless, and all the information is in the database. So if you run multiple instances on top of a single database then they would automatically look the same and changes in one would immediately reflect in the other.
This would “just” be a matter of switching themes. Maybe leverage the existing theme preview logic and have a plugin just look at the hostname instead of the URL parameter.
Hosting the same forum under two URL’s might be the hardest part here, especially with respect to SEO. It would get you into all kinds of duplicate content and canonical URL trouble.
이 부분을 좀 더 명확히 설명해 주실 수 있을까요? 그것이 어떻게 작동하는지 조금 더 알고 싶습니다. 두 문장이 서로 모순되는 것 같습니다. 모든 것을 반영하는 것이 실제로 OP가 요청한 것인 것 같습니다. 하지만 첫 번째 인스턴스에 의해 이루어진 변경 사항에 대해 다른 인스턴스가 통지를 받지 않는다면 어떻게 가능할까요? 데이터베이스에 저장되기는 하지만, 통지는 없으니까요.
그러면 단순히 db = 상태가 없(stateless)다는 뜻입니다. 요청을 할 때마다 데이터베이스에 다시 물어보는 것이죠 - 메모리 내 상태는 없습니다. 아니면 그런가요?
그렇지 않다면, 플러그인이라는 아이디어를 정말 좋아합니다. 이것이 나아갈 방향이라고 동의하며, 또한 SEO는 선택해서 하는 것이 아니라 청중을 확보하기 위해 어쩔 수 없이 해야 하는 것이라고 여전히 생각합니다. 중복(Duplication)은 실제로 이를 줄이는 방법일 수 있습니다. 사용자의 관점에서도 제가 한 사이트에서 작성한 것을 다른 사이트에서 링크로 보는 것은 의아할 수 있으며, 저는 정말로 불편할 것입니다. 콘텐츠 중복은 일반적으로 저품질 사이트가 사용하는 방법입니다. 그래서 SEO에서 불이익을 받습니다. 하지만 이것은 Community Building(커뮤니티 구축) 카테고리에 더 적합한 주제일 것입니다.
I think we’re in a confusion of definitions here. The Discourse server-side code is (kind of*) stateless but the entire Discourse instance (web client, server side code, Redis, cached files, database) is not.
The other side of that medal is that - given that the server-side code is stateless - this setup can’t accomplish what the OP wants, since there is no place to store the information which URL and theme should be served. The setup you’re describing is actually what happens in a load-balancing setup where there are multiple web containers and a single database/Redis instance. It’s a single site.
* I’m saying “kind of” because there are a lot of caching layers in various places
I see. Is the main site URL stored in the database, too? So it is not a matter of a local instance configuration? In that case it would be clear that both instances would still try to serve the same thing.
And you are right that two-server setup still doesn’t help Discourse to choose the right theme at all.
Now it reminds me that there would be a problem with the content, too. If you paste a link into Discourse, it posts the whole URL into it. So someone reading a topic authored by the other site would be directed to it when clicking on a link. Same with uploads, see Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
Another problem could be e-mails? From which domain would the notification e-mails go? Another problem – social plugins (Facebook etc.) or Google login would redirect to a wrong site (or maybe refuse the sign-in).
Coming in from left field, a much simpler solution would be to have a single instance with 2 categories - one for each of the parent sites. This would sidestep all of those issues mentioned above.
There is plenty of scope to style categories and topics that are within that category via simple CSS using the category-category_slug class.
If you want to make one or the other the ‘default’ or home for a set of users, then Custom Homepage for Groups would be the tool you need.
