Discourseは2つの異なるスタイルのWebサイトに対して、共有フォーラムをサポートできますか？

インストール
1

こんにちは、Discourseコミュニティの皆さん、

私は、自分のブログとポートフォリオという2つの別々のウェブサイトで共有フォーラムを作成する可能性を検討しています。コンセプトは、両方のサイトにサービスを提供する1つのフォーラムデータベースを持ち、ユーザーとトピックを2つのコミュニティ間で共有できるようにすることです。しかし、ユーザーが訪問しているサイトに応じてフォーラムのスタイルを異なったものにしたいと考えており、これにより、より大きな共有スペースの一部でありながら、各コミュニティが独自性を感じられるようにしたいです。

私はウェブ開発のバックグラウンドを持っていますが、このような大規模なプロジェクトにしばらく取り組んでいませんでした。必要なことを学び、このプロジェクトを実現するために再び取り組む意欲はありますが、Discourseでこれが実現可能かどうか、ガイダンスをいただけると幸いです。

具体的には、以下の点について疑問に思っています。

  1. Discourseは、参照元のドメインまたはURLに基づいて、異なるテーマやスタイルをサポートできますか？
  2. 共有ユーザーデータベースとトピックプールを維持しながら、Discourseをカスタムブランディング（ロゴ、色など）を表示するように構成することは可能ですか？
  3. これを実装しやすくするプラグインや拡張機能はありますか？
  4. このようなセットアップを追求する際に考慮すべき課題や制限について、何かアドバイスはありますか？

このプロジェクトはまだ構想段階であり、年末に向けて構築を開始する予定です。このビジョンにDiscourseが適切なプラットフォームであるかを確認してから、コミットしたいと考えています。

洞察、提案、またはリソースを提供していただければ、事前に感謝いたします。

よろしくお願いいたします。
Chris

「いいね！」 4
2

ブログ用とポートフォリオ用のフォーラムが2つあり、同じデータベースを共有するということですか？

「いいね！」 1
3

正しいです。
両方のドメインは1つのデータベース上に配置された1つのフォーラムを共有しています。テーマ設定のみが異なります。

「いいね！」 1
4

あまり詳しく調べていませんが、マルチサイトの設定で可能かもしれません。

しかし、マルチサイトの設定に関する私の知識と経験を持つ誰かからのフィードバックが必要になります。

「いいね！」 1
5

まだよくわかりません。
ドメインaはフォーラムを指し、ドメインbは同じフォーラム/同じデータベースを持つ別のフォーラムを指すということですか？もしそうなら、同じデータベースを持つ別のフォーラムでしょうか？そうすれば、スタイルは異なる可能性があります。

このガイドがお役に立つかもしれません。

その後、両方のフォーラムがそこを指すことができますか？

「いいね！」 2
6

ここで簡単に検索してみましたが、それが簡単にできるかどうかはわかりません。

より簡単な方法は、プライマリグループに紐付けられたトグルを使用し、グループAからグループBに切り替えることでテーマを変更する2つのグループを用意し、Theme component カスタムホームページをグループ用に使うことかもしれません。あるいは、Modern Category+group boxes を2回使用し（air theme で使用）、テーマ/プライマリグループに基づいてカスタマイズすることも考えられます。

私自身はわかりませんが、Discourse を2つインストールするとデータベースが破損するリスクがあるのではないかと思います。ステージングサイトを持っている人もいますが、ステージングサイトは通常、メインサイトから定期的にバックアップされていると思います。

「いいね！」 2
7

サイトAを開き、サイトAからフォーラムに移動すると、テーマAが適用されます。

その後、同じユーザーがサイトBを開き、サイトBからフォーラムに移動すると、テーマBが表示されますか？

ユーザーがテーマAを適用した状態でサイトBを開き、フォーラムページを更新した場合はどうなりますか？テーマBが適用されますか、それともテーマAが維持されますか？

8

同じデータベース上で複数のエンジン（Discourseのインストール）を実行できると推測します（そのため、別のデータベースが必要です）。ただし、sidekiqは1つだけ実行することをお勧めします。そうしないと、2つがジョブの奪い合いを始める可能性があります。それ以外は、Discourseはステートレスアプリケーションなので、いくつ実行しても問題ないはずです。

さて、問題の根本に関する質問ですが、なぜですか？そして、それはSEOルールに違反しないのでしょうか？Googleは、同じコンテンツが複数のサイトで見つかることを嫌うと思います。

「いいね！」 3
9

実際には、期待どおりに動作しないものがあるかもしれません。例えば、リアルタイムのUI更新（誰かが記事を更新して、読んでいる間に魔法のように再レンダリングされる場合）などです。2つのサイトはお互いに通知しないと思うので、ユーザーがブラウザを更新することに依存する必要があるでしょう。他にもあるかもしれません。例えば、一方のサイトでサイト設定を変更した場合、もう一方のサイトもそれに気づかず、もう一方を再起動する必要があるかもしれません。

Scaling up and sidekiq に基づくと、これは実際に解決可能であるように思われます。Sidekiqがそれを処理し、残りはRedisを正しく設定する問題になるでしょう。

「いいね！」 2
10

少しトピックから外れますが、会話を逸らしたくないので、単純な感謝の意を加えたいと思います。

インターネット時代においては、SEOかユーザーのどちらかを考える必要があると思います。

そして、セルフホスト型のDiscourseは、ユーザーを選ぶ人々によって使用されると確信しています。

私は、同じようなオーディエンスとターゲットを持つ個人的なプロジェクトのためにこの機能を探していました。マルチサイトとSSOが最も近いものでしたが、遅くて不便なので、どこにもたどり着けませんでした。

OPのアイデアを支持し、フォローし始めます👍

「いいね！」 2
11

リファラーに基づいてユーザーのテーマを変更することは可能でしょうか？プラグインが必要になると思います。

私に連絡するか、Marketplace で質問してください。

「いいね！」 4
12

マルチサイトは機能しません、皆さん。

これも機能しません。

Discourseはステートレスではなく、すべての情報はデータベースにあります。そのため、単一のデータベースの上に複数のインスタンスを実行すると、それらは自動的に同じように見え、一方での変更はもう一方に即座に反映されます。

これは「単に」テーマを切り替える問題になるでしょう。既存のテーマプレビューロジックを活用し、URLパラメータではなくホスト名を見るだけのプラグインを作成することも考えられます。

同じフォーラムを2つのURLでホストすることは、特にSEOに関して、ここでの最も難しい部分になるでしょう。重複コンテンツや正規URLのトラブルに巻き込まれる可能性があります。

「いいね！」 5
13

それを明確にしていただけますか？それがどのように機能するかもう少し知ることができるのは非常に興味深いです。あなたの2つの文は矛盾していると思いますか？すべてを反映することは、OPが求めていたことだと思います。しかし、一方のインスタンスが最初のインスタンスによって行われた変更について通知されない場合、それはどのように起こり得るのでしょうか？データベースに格納されているのは事実ですが、通知はありません。

したがって、単にdb =ステートレスです。リクエストを行うたびにデータベースに再度問い合わせます。インメモリ状態はありません。それともありますか？

そうでなければ、プラグインのアイデアは本当に気に入っています。これが進むべき道であることに同意しますし、SEOは選択するものではなく、聴衆を獲得するためには何とかして行わなければならないものであると今でも考えています。重複は実際に対策を講じる方法になります。ユーザーの観点から見ても、自分が書いたものが、まったく知らない別のサイトにリンクされているのを見ると、疑わしく感じるかもしれません。本当に動揺するでしょう。コンテンツの重複は、通常、低品質のサイトで使用される手法です。そのため、SEOの評価が下がります。しかし、これは#communityカテゴリのトピックになるでしょう。

14

ここでは定義の混乱があると思います。Discourseのサーバーサイドコードは（ある意味で*）ステートレスですが、Discourseインスタンス全体（Webクライアント、サーバーサイドコード、Redis、キャッシュファイル、データベース）はステートレスではありません。

その裏返しとして、サーバーサイドコードがステートレスであるという事実を考慮すると、OPが望むことはこのセットアップでは達成できません。なぜなら、どのURLとテーマを提供すべきかの情報を保存する場所がないからです。あなたが説明しているセットアップは、実際には、複数のWebコンテナと単一のデータベース/Redisインスタンスがあるロードバランシングセットアップで起こることです。それは単一のサイトです。

「ある意味で」と言っているのは、さまざまな場所に多くのキャッシングレイヤーがあるためです

「いいね！」 3
15

なるほど。メインサイトのURLもデータベースに保存されているのですか？それなら、ローカルインスタンスの設定の問題ではないということですね。その場合、両方のインスタンスが同じものをサービスしようとするのは明らかです。

そして、2台構成でもDiscourseが適切なテーマを選択するのに全く役立たないというのは、おっしゃる通りです。

今思い出したのですが、コンテンツにも問題があるでしょう。Discourseにリンクを貼り付けると、URL全体が貼り付けられます。そのため、他のサイトで作成されたトピックを読んでいる人は、リンクをクリックするとそこに誘導されることになります。アップロードも同様で、Uploads Path Should Update When URL Changes in app.yml During Container Rebuild を参照してください。

別の問題はメールでしょうか？通知メールはどのドメインから送信されますか？別の問題として、ソーシャルプラグイン（Facebookなど）やGoogleログインは、間違ったサイトにリダイレクトされる（あるいはサインインを拒否する）可能性があります。

16

左翼から来る、はるかに簡単な解決策は、単一のインスタンスに2つのカテゴリを持つことです。親サイトごとに1つずつ。これにより、上記で述べたすべての問題が回避されます。

カテゴリと、そのカテゴリ内のトピックは、category-category_slug クラスを使用した簡単なCSSでスタイルを設定する十分な余地があります。

いずれかを特定のユーザーセットの「デフォルト」またはホームページにしたい場合は、Custom Homepage for Groups が必要なツールになります。

「いいね！」 5