これはおそらくばかげた質問ですが、頭の中でクリックするだけではありません。
Djangoでは、アプリ固有のすべての静的ファイル(css、js)をstaticというフォルダーに配置するのが慣例です。したがって、構造は次のようになります。
mysite/
manage.py
mysite/ --> (settings.py, etc)
myapp/ --> (models.py, views.py, etc)
static/
Mysite/settings.pyには次のものがあります。
STATIC_ROOT = 'staticfiles'
したがって、コマンドを実行すると:
python manage.py collectstatic
ルートレベルでstaticfilesというフォルダーを作成します(myapp /と同じディレクトリ)
これのポイントは何ですか?すべての静的ファイルのコピーを作成するだけではありませんか?
さて、単一のDjangoprojectは複数のappsしたがって、myapp
は1つしかありませんが、実際にはmyapp1
、myapp2
などになります。
個々のアプリ内からそれらを単一のフォルダーにコピーすることにより、フロントエンドWebサーバー(nginxなど)をその単一のフォルダーSTATIC_ROOT
に向け、静的なファイルを単一の場所から提供するように設定できます。複数のパスからの静的ファイル。
バージョン管理のためにファイル名に追加されるMD5ハッシュに関する注意:settings.STATICFILES_STORAGE
はcollectstatic
にデフォルト設定されるため、StaticFilesStorage
のデフォルト動作の一部ではありません(これは行われません)
MD5ハッシュは、たとえばManifestStaticFilesStorage
を使用するように設定した場合、その動作を広告します。
このストレージの目的は、いくつかのページがまだそれらのファイルを参照している場合に古いファイルを提供し続けることです。それらはあなたまたはサードパーティのプロキシサーバーによってキャッシュされるためです。さらに、展開されたファイルに遠い将来のExpiresヘッダーを適用して、後続のページアクセスのロード時間を短縮したい場合にも非常に役立ちます。
Djangoの静的ファイルは多くの場所に配置できます。 /static/img/icon.png
として提供されるファイルは、 多くの場所から来る です。デフォルトでは:
FileSystemFinder
は、img/icon.png
のそれぞれでSTATICFILES_DIRS
を探します。AppDirectoriesFinder
は、img/icon.png
のそれぞれのstatic
サブフォルダーでINSTALLED_APPS
を探します。これにより、Django Adminなどのライブラリが独自の静的ファイルをアプリに追加できます。現在:これは、DEBUG = 1でmanage.py runserver
を実行した場合にのみ機能します。ライブに移行すると、Djangoプロセスは静的アセットを提供しなくなります。これらにサービスを提供するためにDjangoを使用するのは非効率的です。そのための特別なツールがさらにあります。
代わりに、次のようにする必要があります。
static
ディレクトリ)/static/*
を直接提供し、他の要求をDjangoにリダイレクトします。collectstatic
は、このディレクトリを準備する既製のスクリプトであるため、展開スクリプトに直接接続できます。
実稼働インストールでは、永続URLが必要です。ファイルの内容が変更されない限り、URLは変更されません。
これは、クライアントがDjangoからWebページを開くときに、コンピューターに誤ったバージョンのCSSまたはJSファイルを保持することを防ぐためです。 Django staticfilesはファイルの変更を検出し、それに応じてURLを更新します。これにより、CSSまたはJSファイルが変更された場合、Webブラウザーは新しいバージョンをダウンロードします。
これは通常、collectstatic
の実行中にファイル名にMD5ハッシュを追加することで実現されます。
編集:複数のアプリに関連する回答も参照してください。
サイト内に複数のDjangoアプリがある場合に便利です。
collectstatic
は、すべてのアプリから静的ファイルを1か所で収集します。これにより、運用環境で提供できるようになります。