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.
Hier eine schnelle Suche, ich bin mir nicht sicher, ob das zu einfach gemacht werden könnte.
Ein vielleicht einfacherer Weg wäre, einen Schalter zu verwenden, der an die primäre Gruppe gebunden ist, und zwei Gruppen zu haben, die beim Wechsel von Gruppe A zu Gruppe B die Themen wechseln und vielleicht etwas wie die Theme component benutzerdefinierte Homepage für Gruppen verwenden? Oder vielleicht werden moderne Kategorie+Gruppenboxen zweimal verwendet (wie im Air-Theme), mit Anpassungen basierend auf Thema/primärer Gruppe
Obwohl ich es selbst nicht weiß. Ich würde mich fragen, ob zwei Discourse-Installationen die Datenbank beschädigen könnten? Obwohl einige Staging-Sites haben, aber ich denke, die Staging-Site wird routinemäßig von der Haupt-Site 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önnen Sie das bitte klarstellen? Es wäre wirklich interessant zu erfahren, wie das funktioniert. Ich denke, Ihre beiden Sätze widersprechen sich? Ich denke, dass die Widerspiegelung von allem tatsächlich das ist, wonach der OP gefragt hat. Aber wie könnte das passieren, wenn die andere Instanz nicht über eine Änderung informiert wird, die von der ersten Instanz vorgenommen wurde? Es ist in der Datenbank gespeichert, ja, aber es gibt keine Benachrichtigung.
Also ist nur eine DB = zustandslos. Jedes Mal, wenn Sie eine Anfrage stellen, fragt sie die Datenbank erneut – es gibt keinen In-Memory-Zustand. Oder doch?
Ansonsten gefällt mir die Idee eines Plugins wirklich gut. Ich stimme zu, dass dies der richtige Weg wäre, und ich denke immer noch, dass SEO nichts ist, wofür man sich entscheidet, sondern irgendwie tun muss, um ein Publikum zu bekommen. Duplizierung wäre eine Möglichkeit, dies tatsächlich zu reduzieren. Selbst aus der Sicht des Benutzers könnte es verdächtig sein, wenn ich etwas sehe, das ich auf einer Website geschrieben habe, vielleicht auf einer anderen Website verlinkt, von der ich keine Ahnung hatte, ich wäre wirklich beunruhigt. Inhaltsduplizierung ist typischerweise eine Methode, die von minderwertigen Websites verwendet wird. Deshalb erhält sie ein SEO-Downgrade. Aber das wäre eher ein Thema für die Kategorie Community.
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.
