問題を解決する可能性はたくさんあります-コード/モデルを共有することは最大の問題ではありません。それらを再利用可能なアプリにパッケージ化すると、さまざまなプロジェクトでそれらを使用できるはずです。
Django の Sites フレームワークを使用する: したがって、両方のサイトは基本的に同じコードで実行され、同じデータベースを使用します。コンテンツ オブジェクトには をForeignKey
指す がありSite
ます。これは、サイトの機能がまったく同じで、デザインが異なるだけの場合にうまく機能します。1 つのサイトをカスタマイズするために Python コードをさらに掘り下げる必要がある場合、これはおそらく最良の選択肢ではありません。
ユーザー用のデータベースと各サイト用のデータベースを備えたソリューションを見つけ、DB ルーターを使用してユーザーを共有できます。これの主な欠点は、ユーザー データとその他のデータが別々のデータベースに存在することです。つまり、それらに対して JOIN などを実行できないということです。(これにより、データが非常にきれいに分離されます。一部のコンテンツがサイトに属しているかどうかをフィルタリングする必要はありません)
各プロジェクトが独自のデータベースに対してではなく、外部サービスに対してユーザーを認証するように、独自の認証バックエンドを作成します。
サイト フレームワークを使用するのが最も簡単だと思いますが、あるサイトが他のサイトに影響を与える可能性のあるより深いカスタマイズ (インスタンスごとの他のデータベース スキーマなど) が必要な場合、これは難しくなる可能性があり、すべての変更が他のサイトにも影響を与える可能性があることに留意する必要があります。サイト。
このソリューションを構成するには、サイトごとに個別の設定ファイルが必要です (少なくともサイトごとに設定する必要がありますSITE_ID
)。さらに、サイトごとに異なるテンプレート フォルダなどの追加設定を個別に指定できます。
settings
__init__.py
base.py
site_a.py
# site_a.py
from base import *
SITE_ID = 1
# eg different templates for this site
TEMPLATE_DIRS = (('site_a/templates/'),)
で実行できる開発サーバーmanage.py --settings settings.site_a
。たとえば、次のことができます。urls.py
設定で指定した場合は、サイトごとに異なるものも使用します。本番環境では、2 つのインスタンスを実行する必要があります。1 つは各サイトの設定で、たとえば . リクエストを適切なインスタンスに送信するリバース プロキシを用意します。