静的ファイル (画像、JavaScript、CSS など) の管理

ウェブサイトではふつう、画像や JavaScript、CSS などの追加のファイルを配信する必要があります。Django では、こうしたファイルのことを「静的ファイル (static files)」と呼んでいます。静的ファイルの管理を簡単にするために、Django は django.contrib.staticfiles を提供しています。

このページでは、こうした静的ファイルの配信の仕方について説明します。

静的ファイルの設定

  1. django.contrib.staticfiles が設定ファイルの INSTALLED_APPS に含まれていることを確認してください。

  2. 設定ファイルの中で、STATIC_URL を設定します。たとえば、次のようになります。

    STATIC_URL = '/static/'

  3. テンプレート中で、静的ファイルへの URL を /static/my_app/myexample.jpg のようにハードコーディングするか、または、より望ましい方法として static テンプレートタグを記述して、設定した STATICFILES_STORAGE ストレージを使うことにより、指定した相対パスから URL を動的に構築します (この方法は特に、静的ファイルを配信する CDN を切り替えたくなった時に、作業を簡単にしてくれます)。

    {% load static %}
<img src="{% static "my_app/example.jpg" %}" alt="My image"/>

  4. アプリケーション内に static``というフォルダを作って静的ファイルを保存してください。例えば、``my_app/static/my_app/example.jpg となります。

ファイルを配信する

これらの設定の手順に加えて、実際に静的ファイルを配信する必要があります。

開発中に django.contrib.staticfiles を使用する場合には、DEBUG を True に設定して runserver を実行すれば、自動的に設定が行われます。(詳しくは、django.contrib.staticfiles.views.serve() を参照)

ただし、この方法は 極めて非効率 であり、セキュリティ上の問題がある 可能性が高いため、実際の製品では使うべきではありません。

製品環境中で静的ファイルを配信するための適切な戦略については、静的ファイルのデプロイ を読んでください。

プロジェクトには、特定のアプリケーションに紐付けられていない 静的な assets があることがあります。その場合には、アプリケーション内の static/ ディレクトリの他に、設定ファイルでディレクトリのリスト (STATICFILES_DIRS) を定義して、Django が静的ファイルを検索できるようにすることができます。たとえば、次のように設定します。

STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),
    '/var/www/static/',
]

staticfiles がファイルを探索する方法について詳しくは、 STATICFILES_FINDERS のドキュメントを参照してください。

静的ファイルの名前空間

Now we might be able to get away with putting our static files directly in my_app/static/ (rather than creating another my_app subdirectory), but it would actually be a bad idea. Django will use the first static file it finds whose name matches, and if you had a static file with the same name in a different application, Django would be unable to distinguish between them. We need to be able to point Django at the right one, and the easiest way to ensure this is by namespacing them. That is, by putting those static files inside another directory named for the application itself.

Serving static files during development

If you use django.contrib.staticfiles as explained above, runserver will do this automatically when DEBUG is set to True. If you don’t have django.contrib.staticfiles in INSTALLED_APPS, you can still manually serve static files using the django.contrib.staticfiles.views.serve() view.

This is not suitable for production use! For some common deployment strategies, see 静的ファイルのデプロイ.

For example, if your STATIC_URL is defined as /static/, you can do this by adding the following snippet to your urls.py:

from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    # ... the rest of your URLconf goes here ...
] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

注釈

This helper function works only in debug mode and only if the given prefix is local (e.g. /static/) and not a URL (e.g. http://static.example.com/).

Also this helper function only serves the actual STATIC_ROOT folder; it doesn’t perform static files discovery like django.contrib.staticfiles.

Serving files uploaded by a user during development

During development, you can serve user-uploaded media files from MEDIA_ROOT using the django.contrib.staticfiles.views.serve() view.

This is not suitable for production use! For some common deployment strategies, see 静的ファイルのデプロイ.

For example, if your MEDIA_URL is defined as /media/, you can do this by adding the following snippet to your urls.py:

from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    # ... the rest of your URLconf goes here ...
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

注釈

This helper function works only in debug mode and only if the given prefix is local (e.g. /media/) and not a URL (e.g. http://media.example.com/).

テスト

When running tests that use actual HTTP requests instead of the built-in testing client (i.e. when using the built-in LiveServerTestCase) the static assets need to be served along the rest of the content so the test environment reproduces the real one as faithfully as possible, but LiveServerTestCase has only very basic static file-serving functionality: It doesn’t know about the finders feature of the staticfiles application and assumes the static content has already been collected under STATIC_ROOT.

Because of this, staticfiles ships its own django.contrib.staticfiles.testing.StaticLiveServerTestCase, a subclass of the built-in one that has the ability to transparently serve all the assets during execution of these tests in a way very similar to what we get at development time with DEBUG = True, i.e. without having to collect them using collectstatic first.

Deployment

django.contrib.staticfiles provides a convenience management command for gathering static files in a single directory so you can serve them easily.

  1. Set the STATIC_ROOT setting to the directory from which you’d like to serve these files, for example:

    STATIC_ROOT = "/var/www/example.com/static/"

  2. Run the collectstatic management command:

    $ python manage.py collectstatic

    This will copy all files from your static folders into the STATIC_ROOT directory.

  3. Use a web server of your choice to serve the files. 静的ファイルのデプロイ covers some common deployment strategies for static files.

さらに学ぶ

This document has covered the basics and some common usage patterns. For complete details on all the settings, commands, template tags, and other pieces included in django.contrib.staticfiles, see the staticfiles reference.

Back to Top