単一サイトとサブサイトvsマルチサイトインストール+スケーラビリティ
私は、非常にスケーラブルである必要がある新しいDrupalプロジェクトを開始しています。現在および最終的なプロジェクトのニーズに基づいて、構造がどのように見えるかを決定する必要があります。以前は、すべての個別のDrupalサイトを使用して同様の目標を達成しましたが、少なくとも、意味のある場合は、メンテナンスの負荷が少し少ないものを検討したいと思います。続行する方法についてのアイデアやアドバイスは大歓迎です...ありがとう。
プレイヤー：
-組織A（主要組織）
-組織B
-組織C
-組織D
（そして将来的にはもっと増えるかもしれません）
関数：
-すべての組織が上陸するサイトのメインのパブリック「フロントエリア」：orga.site.com
-組織Aのメンバーのアクセス制限エリア：orga.site.com
-組織Bのメンバーのアクセス制限エリア：orga.site.com/orgb
-組織Cのメンバーのアクセス制限エリア：orga.site.com/orbc
-組織Dのメンバーのアクセス制限エリア：orga.site.com/orgd
アクセス制限された領域は、組織間で類似した機能を持っていますが、完全に同じではなく、制限された領域内の組織ごとにルックアンドフィール（テーマ）は異なります。
さらに、各組織のアクセス制限エリアには、さらに小さなグループに制限されたサブエリアがあります。例：
組織B：
-メインフロント：orga.site.com
-組織Bのすべてのメンバーがアクセスできる制限付きエリア：orga.site.com/orgb
-組織Bのサブグループに制限された領域：orga.site.com/orgb/groupa
-組織Bの別のサブグループに制限された領域：orga.site.com/orgb/groupb
このタイプのサブサイトの差別化は、各組織にとって典型的なものです。
通常、私がこのようにプロジェクトをマッピングするとき、私はどのように進めるかについての良いハンドルを持っています。この場合、私の頭はまだ少し回転しているので、入力は役に立ちます。
このようなサイトを構築するには、多くの可能な方法があります。最初から、マルチサイト設定を使用しないことをお勧めします。 c.f. Drush pm-update and multisite 。これに複数のDrupalサイトを使用したい場合は、vhost confファイルのエイリアスを使用して、/ orgb、/ orgcなどを別のDrupalルートにポイントします。
ただし、この特定のケースでは、単一のDrupalサイトを Organic Groups および Organic Groups Theme で使用するのが最善の方法だと思います。免責事項：latterモジュールは最小限に維持され、私は個人的には使用していません。 orga.site.com/orgbの代わりにorgb.site.comをサポートしたい場合は、代わりに Domain Access または Subdomain モジュールを使用できますが、ドメインアクセス ドメインアクセスとオーガニックグループ の問題に注意する必要があります。いくつかの実験を試して、実装全体に飛び込んで実行する前に、それらがどのようにユースケースに適合するかを確認してください。あなたはかなり簡単に楽しいものを設定できるはずです。