ich erkunde die Möglichkeit, ein gemeinsames Forum für zwei separate Websites zu erstellen, meinen Blog und mein Portfolio. Das Konzept ist, eine einzige Forendatenbank zu haben, die beide Seiten bedient, sodass Benutzer und Themen über die beiden Communities hinweg geteilt werden können. Allerdings möchte ich, dass das Forum je nach besuchter Website unterschiedlich gestaltet wird, damit sich jede Community deutlich abhebt und dennoch Teil des größeren gemeinsamen Raums ist.
Ich habe einen Hintergrund in der Webentwicklung, auch wenn ich schon länger nicht mehr an einem so großen Projekt gearbeitet habe. Ich bin bereit, mich wieder einzuarbeiten und zu lernen, was nötig ist, um dies zu ermöglichen, aber ich würde mich über eine Anleitung freuen, ob dies mit Discourse machbar ist.
Insbesondere frage ich mich:
Kann Discourse unterschiedliche Themen oder Stile basierend auf der verweisenden Domain oder URL unterstützen?
Ist es möglich, Discourse so zu konfigurieren, dass benutzerdefinierte Markenzeichen (Logos, Farben usw.) angezeigt werden, während eine gemeinsame Benutzerdatenbank und ein gemeinsamer Themenpool beibehalten werden?
Gibt es Plugins oder Erweiterungen, die die Implementierung erleichtern könnten?
Irgendwelche Ratschläge zu Herausforderungen oder Einschränkungen, die ich bei der Verfolgung dieser Art von Einrichtung berücksichtigen sollte?
Dieses Projekt befindet sich noch in der Konzeptionsphase, und ich plane, gegen Ende des Jahres mit dem Aufbau zu beginnen. Ich möchte sicherstellen, dass Discourse die richtige Plattform für diese Vision ist, bevor ich mich festlege.
Vielen Dank im Voraus für alle Erkenntnisse, Vorschläge oder Ressourcen, die Sie bereitstellen können!
Ich bin immer noch nicht ganz klar.
Zeigt Domain A auf das Forum und Domain B auf dasselbe Forum/ein anderes Forum mit derselben Datenbank? Wenn ja, vielleicht ein anderes Forum mit derselben Datenbank? Dann kann der Stil unterschiedlich sein.
Eine kurze Suche hier zeigt, dass es nicht unbedingt einfach zu bewerkstelligen wäre.
Ein möglicherweise einfacherer Ansatz könnte sein, einen Schalter mit der Hauptgruppe zu verknüpfen und zwei Gruppen zu verwenden, wobei der Wechsel von Gruppe A zu Gruppe B das Theme wechselt. Vielleicht lässt sich dafür etwas wie die benutzerdefinierte Startseite für Gruppen (Customization > Theme component) nutzen? Oder man installiert die modernen Kategorie- und Gruppenboxen (wie im Air-Theme verwendet) doppelt und passt sie basierend auf dem Theme oder der Hauptgruppe an.
Ich weiß es zwar nicht genau, aber ich frage mich, ob zwei separate Discourse-Installationen das Risiko einer Beschädigung der Datenbank bergen könnten. Zwar gibt es einige Staging-Umgebungen, aber ich glaube, die Staging-Seite wird regelmäßig von der Hauptinstanz gesichert?
Wenn ein Benutzer also Website A öffnet, vom Website A zum Forum wechselt, wird dann Thema A angewendet?
Wenn derselbe Benutzer dann Website B öffnet, vom Website B zum Forum wechselt und Thema B sieht?
Was ist, wenn für den Benutzer Thema A angewendet wurde, er zu Website B wechselt und die Forumseite aktualisiert? Wird dann Thema B angewendet oder behält es Thema A bei?
Meine Vermutung ist, dass Sie mehrere Engines (Discourse-Installationen) auf derselben Datenbank ausführen können (daher benötigen Sie eine separate Datenbank). Ich würde jedoch nur 1 Sidekiq ausführen. Andernfalls würden sich zwei davon um die Jobs streiten. Ansonsten denke ich, dass Discourse eine zustandslose App ist, daher sollte es keine Rolle spielen, wie viele Sie ausführen.
Nun eine Frage zum Kern des Problems: Warum? Und verstößt es nicht gegen SEO-Regeln? Ich glaube, Google mochte es nicht, wenn es denselben Inhalt auf mehreren Websites fand.
Tatsächlich funktionieren möglicherweise einige Dinge nicht wie erwartet – z. B. Echtzeit-UI-Updates (wenn jemand einen Artikel aktualisiert, sodass er sich magisch neu rendert, während Sie ihn lesen). Ich denke, die beiden Websites würden sich nicht gegenseitig informieren, sodass Sie darauf angewiesen wären, dass der Benutzer seinen Browser aktualisiert. Es könnte mehr geben. Wenn Sie beispielsweise die Website-Einstellungen auf einer Website ändern, würde die andere Website dies wahrscheinlich auch nicht bemerken und Sie müssten die andere neu starten.
Basierend auf Scaling up and sidekiq scheint es mir, dass dies tatsächlich lösbar ist. Sidekiq scheint damit umzugehen und der Rest wäre eine Frage der korrekten Konfiguration von Redis.
Das ist ein wenig vom Thema abweichend, und ich möchte das Gespräch nicht ablenken, aber ich möchte meine einfache Wertschätzung hinzufügen.
Ich denke, wir befinden uns in einem Internetzeitalter, in dem man über SEO oder seine Benutzer nachdenken muss.
Und ich habe keinen Zweifel daran, dass selbst gehostetes Discourse von denen genutzt wird, die sich für ihre Benutzer entscheiden.
Ich habe nach dieser Funktion gesucht, weil ich persönliche Projekte mit dem gleichen Publikum und Ziel habe. Multisite mit SSO war das Nächstliegende, aber ich bin nirgendwo gelandet, weil es langsam und nicht praktisch ist.
Ich unterstütze die Idee des OP und fange an, dies zu verfolgen
Discourse ist nicht zustandslos, und alle Informationen befinden sich in der Datenbank. Wenn Sie also mehrere Instanzen auf einer einzigen Datenbank ausführen, würden sie automatisch gleich aussehen und Änderungen in einer würden sich sofort in der anderen widerspiegeln.
Dies wäre “nur” eine Frage des Wechsels der Themes. Vielleicht die vorhandene Theme-Vorschau-Logik nutzen und ein Plugin nur den Hostnamen anstelle des URL-Parameters betrachten lassen.
Das Hosting desselben Forums unter zwei URLs könnte hier der schwierigste Teil sein, insbesondere in Bezug auf SEO. Sie würden in alle Arten von Problemen mit doppeltem Inhalt und kanonischen URLs geraten.
Könntest du das bitte erläutern? Es wäre wirklich interessant zu erfahren, wie das im Detail funktioniert. Ich habe das Gefühl, dass deine beiden Sätze sich widersprechen? Ich denke, genau das spiegeln der Daten war es, wonach der OP gefragt hat. Aber wie könnte das geschehen, wenn die andere Instanz nicht über eine Änderung benachrichtigt wird, die von der ersten Instanz durchgeführt wurde? Die Daten werden ja in der Datenbank gespeichert, aber es gibt keine Benachrichtigung.
Also vereinfacht gesagt: db = zustandslos. Jedes Mal, wenn eine Anfrage gestellt wird, fragt sie erneut die Datenbank ab – es gibt keinen Zustand im Arbeitsspeicher (In-Memory-State). Oder etwa doch?
Ansonsten gefällt mir die Idee eines Plugins wirklich gut. Ich bin einverstanden, dass dies der richtige Weg ist, und ich denke immer noch, dass SEO etwas ist, das man nicht einfach „wählt“, sondern das man irgendwie betreiben muss, um eine Zielgruppe zu erreichen. Duplizierung wäre eine Möglichkeit, dies tatsächlich zu unterbinden. Selbst aus Benutzersicht könnte es verdächtig wirken, wenn ich etwas sehe, das ich auf einer Website verfasst habe, das vielleicht auf einer anderen Website verlinkt ist, von der ich keine Ahnung hatte – das würde mich wirklich stören. Content-Duplizierung ist typischerweise eine Methode, die von Websites mit niedriger Qualität verwendet wird. Deshalb wird dies im SEO abgestraft. Aber das wäre eher ein Thema für die Kategorie Community Building.
Ich denke, wir haben hier eine Begriffsverwirrung. Der serverseitige Code von Discourse ist (irgendwie*) zustandslos, aber die gesamte Discourse-Instanz (Webclient, serverseitiger Code, Redis, zwischengespeicherte Dateien, Datenbank) ist es nicht.
Die Kehrseite ist, dass - da der serverseitige Code zustandslos ist - dieses Setup nicht das erreichen kann, was der OP möchte, da es keinen Ort gibt, an dem die Informationen gespeichert werden können, welche URL und welches Theme bereitgestellt werden sollen. Das von Ihnen beschriebene Setup ist tatsächlich das, was in einem Load-Balancing-Setup passiert, bei dem es mehrere Web-Container und eine einzige Datenbank/Redis-Instanz gibt. Es ist eine einzelne Website.
* Ich sage “irgendwie”, weil es an vielen Stellen verschiedene Caching-Schichten gibt
Ich verstehe. Wird die Haupt-Site-URL auch in der Datenbank gespeichert? Es handelt sich also nicht um eine Konfigurationsfrage der lokalen Instanz? In diesem Fall wäre klar, dass beide Instanzen immer noch versuchen würden, dasselbe bereitzustellen.
Und Sie haben Recht, dass ein Zwei-Server-Setup Discourse überhaupt nicht hilft, das richtige Theme auszuwählen.
Jetzt fällt mir ein, dass es auch ein Problem mit dem Inhalt gäbe. Wenn Sie einen Link in Discourse einfügen, wird die gesamte URL eingefügt. Jemand, der ein Thema liest, das von der anderen Website verfasst wurde, würde beim Klicken auf einen Link dorthin weitergeleitet. Dasselbe gilt für Uploads, siehe Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
Ein weiteres Problem könnten E-Mails sein? Von welcher Domain würden die Benachrichtigungs-E-Mails kommen? Ein weiteres Problem – Social Plugins (Facebook etc.) oder Google Login würden zu einer falschen Website weiterleiten (oder vielleicht die Anmeldung verweigern).
Als unerwartete Lösung käme eine einzelne Instanz mit 2 Kategorien in Frage – eine für jede der übergeordneten Websites. Dies würde all die oben genannten Probleme umgehen.
Es gibt viel Spielraum, um Kategorien und Themen, die sich innerhalb dieser Kategorie befinden, über einfaches CSS mit der Klasse category-category_slug zu gestalten.
Wenn Sie eine der beiden als „Standard“ oder Startseite für eine Gruppe von Benutzern festlegen möchten, dann wäre Custom Homepage for Groups das richtige Werkzeug dafür.
