こんにちは、Discourseコミュニティの皆さん、
私は、自分のブログとポートフォリオという2つの別々のウェブサイトで共有フォーラムを作成する可能性を検討しています。コンセプトは、両方のサイトにサービスを提供する1つのフォーラムデータベースを持ち、ユーザーとトピックを2つのコミュニティ間で共有できるようにすることです。しかし、ユーザーが訪問しているサイトに応じてフォーラムのスタイルを異なったものにしたいと考えており、これにより、より大きな共有スペースの一部でありながら、各コミュニティが独自性を感じられるようにしたいです。
私はウェブ開発のバックグラウンドを持っていますが、このような大規模なプロジェクトにしばらく取り組んでいませんでした。必要なことを学び、このプロジェクトを実現するために再び取り組む意欲はありますが、Discourseでこれが実現可能かどうか、ガイダンスをいただけると幸いです。
具体的には、以下の点について疑問に思っています。
- Discourseは、参照元のドメインまたはURLに基づいて、異なるテーマやスタイルをサポートできますか？
- 共有ユーザーデータベースとトピックプールを維持しながら、Discourseをカスタムブランディング（ロゴ、色など）を表示するように構成することは可能ですか？
- これを実装しやすくするプラグインや拡張機能はありますか？
- このようなセットアップを追求する際に考慮すべき課題や制限について、何かアドバイスはありますか？
このプロジェクトはまだ構想段階であり、年末に向けて構築を開始する予定です。このビジョンにDiscourseが適切なプラットフォームであるかを確認してから、コミットしたいと考えています。
洞察、提案、またはリソースを提供していただければ、事前に感謝いたします。
よろしくお願いいたします。
Chris
ブログ用とポートフォリオ用のフォーラムが2つあり、同じデータベースを共有するということですか？
正しいです。
両方のドメインは1つのデータベース上に配置された1つのフォーラムを共有しています。テーマ設定のみが異なります。
Heliosurge
(Dan DeMontmorency)
4
あまり詳しく調べていませんが、マルチサイトの設定で可能かもしれません。
しかし、マルチサイトの設定に関する私の知識と経験を持つ誰かからのフィードバックが必要になります。
まだよくわかりません。
ドメインaはフォーラムを指し、ドメインbは同じフォーラム/同じデータベースを持つ別のフォーラムを指すということですか？もしそうなら、同じデータベースを持つ別のフォーラムでしょうか？そうすれば、スタイルは異なる可能性があります。
このガイドがお役に立つかもしれません。
その後、両方のフォーラムがそこを指すことができますか？
Heliosurge
(Dan DeMontmorency)
6
ここで少し検索してみましたが、これもそれほど簡単にできることではないようです。
もしかしたら、プライマリグループに紐づくトグルを使って、グループAからグループBに切り替えることでテーマを切り替え、さらに #customization:theme-component のようなカスタムホームページをグループごとに用意する方法があるかもしれません。あるいは、Airテーマで使われているような、Modern Category + グループボックスを2つインストールして、テーマやプライマリグループに基づいてカスタマイズする方法もあるかもしれません。
私自身は詳しくありませんが、Discourseのインストールを2つ行うと、データベースが破損するリスクがあるのではないかと疑問に思います。ステージングサイトを用意しているケースもありますが、ステージングサイトはメインのサイトから定期的にバックアップされていると考えています。
Canapin
(Coin-coin le Canapin)
7
サイトAを開き、サイトAからフォーラムに移動すると、テーマAが適用されます。
その後、同じユーザーがサイトBを開き、サイトBからフォーラムに移動すると、テーマBが表示されますか？
ユーザーがテーマAを適用した状態でサイトBを開き、フォーラムページを更新した場合はどうなりますか？テーマBが適用されますか、それともテーマAが維持されますか？
tvavrda
(Tomas Vavrda)
8
同じデータベース上で複数のエンジン（Discourseのインストール）を実行できると推測します（そのため、別のデータベースが必要です）。ただし、sidekiqは1つだけ実行することをお勧めします。そうしないと、2つがジョブの奪い合いを始める可能性があります。それ以外は、Discourseはステートレスアプリケーションなので、いくつ実行しても問題ないはずです。
さて、問題の根本に関する質問ですが、なぜですか？そして、それはSEOルールに違反しないのでしょうか？Googleは、同じコンテンツが複数のサイトで見つかることを嫌うと思います。
tvavrda
(Tomas Vavrda)
9
実際には、期待どおりに動作しないものがあるかもしれません。例えば、リアルタイムのUI更新（誰かが記事を更新して、読んでいる間に魔法のように再レンダリングされる場合）などです。2つのサイトはお互いに通知しないと思うので、ユーザーがブラウザを更新することに依存する必要があるでしょう。他にもあるかもしれません。例えば、一方のサイトでサイト設定を変更した場合、もう一方のサイトもそれに気づかず、もう一方を再起動する必要があるかもしれません。
Scaling up and sidekiq に基づくと、これは実際に解決可能であるように思われます。Sidekiqがそれを処理し、残りはRedisを正しく設定する問題になるでしょう。
少しトピックから外れますが、会話を逸らしたくないので、単純な感謝の意を加えたいと思います。
インターネット時代においては、SEOかユーザーのどちらかを考える必要があると思います。
そして、セルフホスト型のDiscourseは、ユーザーを選ぶ人々によって使用されると確信しています。
私は、同じようなオーディエンスとターゲットを持つ個人的なプロジェクトのためにこの機能を探していました。マルチサイトとSSOが最も近いものでしたが、遅くて不便なので、どこにもたどり着けませんでした。
OPのアイデアを支持し、フォローし始めます👍
pfaffman
(Jay Pfaffman)
11
リファラーに基づいてユーザーのテーマを変更することは可能でしょうか？プラグインが必要になると思います。
私に連絡するか、Marketplace で質問してください。
RGJ
(Richard - Communiteq)
12
マルチサイトは機能しません、皆さん。
これも機能しません。
Discourseはステートレスではなく、すべての情報はデータベースにあります。そのため、単一のデータベースの上に複数のインスタンスを実行すると、それらは自動的に同じように見え、一方での変更はもう一方に即座に反映されます。
これは「単に」テーマを切り替える問題になるでしょう。既存のテーマプレビューロジックを活用し、URLパラメータではなくホスト名を見るだけのプラグインを作成することも考えられます。
同じフォーラムを2つのURLでホストすることは、特にSEOに関して、ここでの最も難しい部分になるでしょう。重複コンテンツや正規URLのトラブルに巻き込まれる可能性があります。
tvavrda
(Tomas Vavrda)
13
それを詳しく説明していただけますか？どのように動作するのかもう少し知りたいので、非常に興味深いです。あなたの二つの文は矛盾しているように思えます。すべての変更を反映させることは、実はOPが求めていることだと考えています。しかし、最初のインスタンスによる変更が他のインスタンスに通知されない場合、どのようにしてそれが可能になるのでしょうか？データベースに保存されるのは確かですが、通知機能はありません。
つまり、データベース＝ステートレスということですか？リクエストがあるたびにデータベースに問い合わせており、メモリ内に状態を保持していないのでしょうか。それとも違いますか？
それ以外では、プラグインのアイデアは本当に気に入りました。それが正解だと同意します。また、SEOは選択して行うものではなく、オーディエンスを獲得するために何らかの形で対応しなければならないものだと今でも考えています。重複は、それを防ぐための方法になり得ます。ユーザーの視点から見ても、あるサイトで書いた内容が、全く知らなかった別のサイトでリンクされているのを見ると、不審に思われ、非常に気になるでしょう。コンテンツの重複は通常、低品質なサイトが使用する手法です。そのため、SEO評価が下がるのです。ただし、これは#community-buildingカテゴリの方が適切な話題かもしれません。
RGJ
(Richard - Communiteq)
14
ここでは定義の混乱があると思います。Discourseのサーバーサイドコードは（ある意味で*）ステートレスですが、Discourseインスタンス全体（Webクライアント、サーバーサイドコード、Redis、キャッシュファイル、データベース）はステートレスではありません。
その裏返しとして、サーバーサイドコードがステートレスであるという事実を考慮すると、OPが望むことはこのセットアップでは達成できません。なぜなら、どのURLとテーマを提供すべきかの情報を保存する場所がないからです。あなたが説明しているセットアップは、実際には、複数のWebコンテナと単一のデータベース/Redisインスタンスがあるロードバランシングセットアップで起こることです。それは単一のサイトです。
「ある意味で」と言っているのは、さまざまな場所に多くのキャッシングレイヤーがあるためです
tvavrda
(Tomas Vavrda)
15
なるほど。メインサイトのURLもデータベースに保存されているのですか？それなら、ローカルインスタンスの設定の問題ではないということですね。その場合、両方のインスタンスが同じものをサービスしようとするのは明らかです。
そして、2台構成でもDiscourseが適切なテーマを選択するのに全く役立たないというのは、おっしゃる通りです。
今思い出したのですが、コンテンツにも問題があるでしょう。Discourseにリンクを貼り付けると、URL全体が貼り付けられます。そのため、他のサイトで作成されたトピックを読んでいる人は、リンクをクリックするとそこに誘導されることになります。アップロードも同様で、Uploads Path Should Update When URL Changes in app.yml During Container Rebuild を参照してください。
別の問題はメールでしょうか？通知メールはどのドメインから送信されますか？別の問題として、ソーシャルプラグイン（Facebookなど）やGoogleログインは、間違ったサイトにリダイレクトされる（あるいはサインインを拒否する）可能性があります。
nathank
(Nathan Kershaw)
16
左翼から来る、はるかに簡単な解決策は、単一のインスタンスに2つのカテゴリを持つことです。親サイトごとに1つずつ。これにより、上記で述べたすべての問題が回避されます。
カテゴリと、そのカテゴリ内のトピックは、category-category_slug クラスを使用した簡単なCSSでスタイルを設定する十分な余地があります。
いずれかを特定のユーザーセットの「デフォルト」またはホームページにしたい場合は、Custom Homepage for Groups が必要なツールになります。