0

開発環境と運用環境の両方に完全な機能を備えた Django アプリケーションがあります。これは、ALLOWED_HOSTS適切に変更するだけで処理され (変更したくない場合DEBUG)、Apache が各場所に適切にサービスを提供するように設定されます。私の問題は、今後のリダイレクトを処理するためにDjango リダイレクト アプリを使用したいということです(このプロジェクトの一部は PHP からの移行です)。これは、Apache でこれらのリダイレクトを処理する必要がなくなったことを意味するためです。リダイレクトはより大きな頭痛の種であり、Apache は index.php リダイレクト ループで問題を引き起こします。また、これにより、管理を容易にするための目標である Django の下でより多くの Web サイト コントロールを移行できるようになります。私が遭遇している問題は、リダイレクトアプリがSITE_IDを使用していることです有効なターゲット/リダイレクトを決定します。本番サーバーは開発用とは異なるホスト名を持っているため、リダイレクト アプリをテストまたは検証できません。これは、ライブに移行する前にすべての機能をテストするという、分離されたほぼ同一の開発サーバーの目的を明らかに損ないます。サイト フレームワークから、個々のサイトには個別の settings.py ファイルとデーモンが共存する必要があることを理解していますが、開発サイトは本番環境から地理的に離れているため、これも私のシナリオには役立ちません。ドキュメントからは明らかではありません:

1) 追加/変更以外のサイトの追加方法SITE_ID- 関連する名前はどこで選択できますか?

2)1を仮定すると、すでに別のsettings.pyファイルがあるので、それが最善の方法です(そして適切です)?

3) 同じサイト エントリが 2 つあるのはfoo.comなぜですか? また、これがリダイレクトにどのように影響しますか? 私は(各サーバーに)単一のwsgiとsettings.pyしかありませんが、

+----+-------------+-------------+
| id | domain      | name        |
+----+-------------+-------------+
|  1 | example.com | example.com |
|  2 | foo.net     | foo.net     |
|  3 | foo.net     | foo         |
+----+-------------+-------------+

私のデータベースで?これらのサイトが追加または構成されている場所がわからないため、リダイレクト アプリに合わせてサイト フレームワークを調整する方法について混乱しています。私はDjango 1.5.4を使用しているため、サイトフレームワークはデフォルトで有効になっているため、これまで考えたこともありませんでした.

4

1 に答える 1

0

リダイレクトは id を使用するだけなので、関連付けられたサイトの名前は重要ではありません。そのため、重複したサイトをすべて削除し、実際のドメイン名に id 1 を残してSITE_ID = 1、運用環境とテスト環境の両方で設定しました。SITE_ID以前はリダイレクトを設定するだけだったので、他のサイトがどこから来たのかはわかりませんが、現在は機能しています。

于 2014-08-04T20:05:45.867 に答える