Splitting a site into two parts

I have a site, lists.tssi.com. It currently supports two essentially independent Discourse communities (migrated from Mailman), handled using groups and categories. Let’s call them x and y.

I want to split it so that the two groups are fully independent. (Yeah, that means more work for me, but I’m OK with that.) The primary reason for doing this is I want to open both communities up to non-member readership, but I think that would be easier if they were fully independent. I don’t think people in community X want to read a lot about what’s happening in community Y, even though they’re similar. (Both are college sports oriented sites.)

One way to do it would be to define the sites as x.tssi.com and y.tssi.com and another way would be to define the sites as x.lists.tssi.com and y.lists.tssi.com.

Either way, lists.tssi.com would act as a gateway to the two communities, with a common front door in Nginx.

As far as I can tell, either method should work in a single container, cloning the database so that they are fully independent. (I set up my testbed server using the x.tssi.com and y.tssi.com method, so I’m sure that works, I’m a bit less sure of the x.lists.tssi.com and y.lists.tssi.com approach, though I think that might be easier for my users to understand and would more readily support additional communities that may be added.)

Once I split them, the users who are part of one community will either be deleted from the other community’s database or just set to inactive. I may also delete all the other site’s posts and categories.

Any recommendations on which way to proceed? Any gotchas to be aware of?

1 Like

Why not retain a central site with users but no content serving discourse connect (SSO) to the two subordinate sites?

I would probably retain the central site with all your users, take two more full copies as x and y, deleting the content I didn’t want from both to create the split, and have them refer to the ‘main’ site for sign-in.

It will also eliminate login confusion for users who may be on both lists.

1 Like

What are the benefits of a SSO environment like that? What are the drawbacks?

I don’t think there are any users on both lists other than me. They were separate Mailman sites for many years, and most of the users are still primarily email based.

Even the need to have separate email addresses to post via email to each category within that community is confusing to some of them, but I don’t see a way around that. I’m encouraging them to use the web interface, but maybe 5% do, 3 months after changeover.

My goal is to expand participation by having both communities web-searchable and readable. It seems to me like keeping them separate might work better for attracting those who want to discuss team X but not team Y.

I’m not in a major hurry, the summer is the slow time for a college sports oriented list, things will start to pick up in August when fall football practice opens. So I’ve got time to think through which approach is better for the communities.

I decided to go with lists.tssi.com for the gateway site and x.tssi.com and y.tssi.com for the separate communities as opposed to x.lists.tssi.com and y.lists.tssi.com. Couldn’t get the latter to work, possibly an ngingx setup issue, it kept rerouting requests for x.lists.tssi.com or y.lists.tssi.com to lists.tssi.com rather than to the Discourse server.

But I can get the other to work, and a working solution is better than a non-working one. :slight_smile: