Aufteilung einer Website in zwei Teile

Unterstützung
1

Ich habe eine Website, lists.tssi.com. Sie unterstützt derzeit zwei im Wesentlichen unabhängige Discourse-Communities (migriert von Mailman), die über Gruppen und Kategorien verwaltet werden. Nennen wir sie x und y.

Ich möchte sie aufteilen, damit die beiden Gruppen vollständig unabhängig sind. (Ja, das bedeutet mehr Arbeit für mich, aber das ist in Ordnung.) Der Hauptgrund dafür ist, dass ich beide Communities für Nicht-Mitglieder zum Lesen öffnen möchte, aber ich glaube, das wäre einfacher, wenn sie vollständig unabhängig wären. Ich glaube nicht, dass Leute aus Community X viel über die Vorgänge in Community Y lesen möchten, obwohl sie ähnlich sind. (Beides sind Websites mit Schwerpunkt auf College-Sport.)

Eine Möglichkeit wäre, die Websites als x.tssi.com und y.tssi.com zu definieren, und eine andere Möglichkeit wäre, die Websites als x.lists.tssi.com und y.lists.tssi.com zu definieren.

In beiden Fällen würde lists.tssi.com als Gateway zu den beiden Communities dienen, mit einer gemeinsamen Eingangstür in Nginx.

Soweit ich das beurteilen kann, sollte jede Methode in einem einzigen Container funktionieren, indem die Datenbank geklont wird, sodass sie vollständig unabhängig sind. (Ich habe meinen Testserver mit der Methode x.tssi.com und y.tssi.com eingerichtet, daher bin ich sicher, dass das funktioniert. Ich bin mir bei der x.lists.tssi.com und y.lists.tssi.com-Methode etwas weniger sicher, obwohl ich denke, dass dies für meine Benutzer leichter zu verstehen wäre und zusätzliche Communities, die möglicherweise hinzugefügt werden, leichter unterstützen würde.)

Sobald ich sie aufgeteilt habe, werden die Benutzer, die Teil einer Community sind, entweder aus der Datenbank der anderen Community gelöscht oder einfach als inaktiv markiert. Möglicherweise lösche ich auch alle Beiträge und Kategorien der anderen Website.

Haben Sie Empfehlungen, wie ich vorgehen soll? Gibt es Fallstricke, auf die ich achten sollte?

1 „Gefällt mir“
2

Warum nicht eine zentrale Website mit Benutzern, aber ohne Inhalte beibehalten, die Discourse Connect (SSO) für die beiden untergeordneten Websites bereitstellt?

Ich würde wahrscheinlich die zentrale Website mit all Ihren Benutzern beibehalten, zwei weitere vollständige Kopien als x und y erstellen, die Inhalte löschen, die ich nicht von beiden wollte, um die Aufteilung zu erstellen, und sie für die Anmeldung auf die „Haupt“-Website verweisen lassen.

Dies wird auch die Anmeldeverwirrung für Benutzer beseitigen, die möglicherweise auf beiden Listen stehen.

1 „Gefällt mir“
3

Welche Vorteile hat eine SSO-Umgebung wie diese? Was sind die Nachteile?

Ich glaube nicht, dass es außer mir noch andere Benutzer in beiden Listen gibt. Sie waren viele Jahre lang getrennte Mailman-Sites, und die meisten Benutzer sind immer noch hauptsächlich per E-Mail erreichbar.

Selbst die Notwendigkeit, separate E-Mail-Adressen zu haben, um per E-Mail an jede Kategorie innerhalb dieser Community zu posten, verwirrt einige von ihnen, aber ich sehe keinen Ausweg. Ich ermutige sie, die Weboberfläche zu nutzen, aber vielleicht 5 % tun dies, 3 Monate nach der Umstellung.

Mein Ziel ist es, die Beteiligung zu erhöhen, indem beide Communities web-suchbar und lesbar gemacht werden. Mir scheint, dass es besser funktionieren könnte, sie getrennt zu halten, um diejenigen anzuziehen, die über Team X, aber nicht über Team Y diskutieren möchten.

Ich habe keine große Eile, der Sommer ist die langsame Zeit für eine Liste, die sich auf College-Sport konzentriert, die Dinge werden im August wieder an Fahrt gewinnen, wenn das Herbst-Football-Training beginnt. Ich habe also Zeit, darüber nachzudenken, welcher Ansatz für die Communities besser ist.

4

Ich habe mich für lists.tssi.com als Gateway-Site und x.tssi.com und y.tssi.com für die separaten Communities entschieden, anstatt für x.lists.tssi.com und y.lists.tssi.com. Ich konnte letzteres nicht zum Laufen bringen, möglicherweise ein Problem mit der nginx-Einrichtung. Es leitete Anfragen für x.lists.tssi.com oder y.lists.tssi.com immer an lists.tssi.com weiter und nicht an den Discourse-Server.

Aber ich kann das andere zum Laufen bringen, und eine funktionierende Lösung ist besser als eine nicht funktionierende. :slight_smile: