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.
Doing a quick search here not sure it would or could be done too easily.
A maybe easier route might be use a toggle tied to primary group and have 2 groups that switching from group A to group B switches Theme’s and maybe uses something like the Theme component Custom Home page for groups? Or perhaps uses Modern Category+group boxes installed twice(used in air theme) with customizations based on theme/primary group
While I don’t know myself. I would wonder if having 2 discourse installs might risk corrupting the database? Though some have staging sites, but I think the staging site is backed up off the main one routinely?
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.
Can you please clarify that? It would be really interesting to know a little more how that works. I think your two sentences contradict? I think that reflecting everything is actually what OP asked for. But how could it happen if the other instance is not notified about a change done by the first instance? It is stored in the database, yes, but there is no notification.
So just a db = stateless. Everytime you make a request it asks the database again - there is no in-memory state. Or is it?
Otherwise I really like the idea of a plugin. I agree that this would be the way to go and I also still think that SEO is not something you choose to do but somehow have to in order to get audience. Duplication would be a way to actually cut it. Even from the user’s point of view it might just be suspicious if I see something I wrote on one site mabye linked on another site I had no idea about, I would be really disturbed. Content duplication is typically a method used by low quality sites. That’s why it gets a SEO downgrade. But this would be more of a topic to Community category.
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.
