2012-03-12 13 views
0

午前中すべて私が配備した以前のDjangoアプリでは遭遇しなかった問題があります。私は、自動化された電子メールリマインダのための管理アプリケーションとカスタム管理コマンドだけを使用する実用的なアプリケーションを持っています。Djangoは、アプリの代わりに "It worked!"と表示しました。(Gunicorn + Nginx)

私の開発マシンでは、このアプリケーションはうまくいきました。動作している管理インターフェイスとカスタム管理コマンドが動作しています。私はdevのマシンからサーバーにプロジェクトディレクトリ全体をコピーしました。私は新しいプロジェクトから期待しています。

私は、プロジェクトが現実のインストールから正確なパス名を持つ場所にそのままコピーされているので、これはちょっと奇妙です。誰でもアイデアはありますか?

編集:下記のコメントに記載されているように、プロジェクトコードと共にコピーした.pycファイルがコンパイルされていることがわかりました。 .pycファイルを移植できない理由を理解するために、Pythonについて十分に知りません。プロジェクトをコピーする前にすべての.pycファイルを削除してからsyncdbを実行すると問題が解決しました。

+0

また、私はブラウザキャッシュを無駄にクリアしました。 – patrickn

+0

urls.pyファイルがコピーされましたか?歓迎の原因は通常、定義されたURLはありません。 – Kekoa

+0

ポストのおかげで、Kekoa - 以下の答えに私のコメントを書き留めてください:私の他のマシンから.pycファイルが干渉していたことがわかります。 – patrickn

答えて

1

^$パターン(基本的に空のURL)のURLマップがあることを確認してください。パスコンポーネントなしでURLを入力するだけでロードされるものです。 = ^/$

example.com = ^$

example.com/APPEND_SLASH設定は、この(その上のデフォルト)に役立ちますが。

プロダクションで行うべきであるDEBUGをオフにすると、そのページは表示されなくなります。それぞれのエラー条件に対して404.html500.htmlテンプレートを提供する必要があります。

+0

ポストに感謝、burhan。私は自分の質問に答えるだろうが、まだ十分な担当者がいない。問題は、プロジェクトと一緒にコピーした.pycファイルのコンパイルです。彼らは何らかの形で干渉していました。 – patrickn

+0

また、私に指摘したことの1つは、DEBUG = Falseを設定しても「それは機能しました!」と表示されていたことです。ページ。実際の.pyファイルを実行するのではなく、コンパイルされたpythonファイルを提供していたことが分かりました。 ./manage.py syncdbは.pycファイルもすでに存在していたため、何もしていませんでした。ストーリーの倫理観 - devからプロダクションサーバーにプロジェクトをコピーする場合、.pycファイルを削除してください! :) – patrickn

+0

答えが.pycファイルの問題のない人に役立つので、あなたの答えをいいました。 – patrickn

関連する問題