Django: Настраиваем STATIC_ROOT, STATICFILES_DIRS и MEDIA_ROOT правильно

Для начала определимся с разницей между статикой и медиа-файлами в терминах Django. Первое — это все ваши файлы, которые вы сами создавали: css-стили, js-скрипты, картинки для дизайна и т.п. Медиа-файлы — всё, что загружает пользователь на ваш сервер (автарки, фотки), т.е. пользовательский контент. С пользовательским контентом всё более-менее просто и поэтому мы рассмотрим настройку только в конце поста.

Честно говоря, я как-то упустил из виду когда появилось встроенное приложение django.contrib.staticfiles, поэтому, столкнулся с ним только на последнем проекте, пришлось потратить какое-то время чтобы понять что к чему и почему не достаточно использовать просто STATIC_ROOT, как раньше.

Итак, сначала ответим на последний вопрос: главная проблема использования в Django просто STATIC_ROOT в качестве указателя пути до статики заключается в том, что не вся наша статика может быть связана с нашим проектом. Ущербность такого подхода ощущал каждый, кто подключал статику встроенной в Django админки на боевом сервере — приходилось либо делать ссылку на папку в дебрях Django со статикой для админки, либо вообще копировать всё оттуда в STATIC_ROOT. А представьте если таких приложений с нужной статикой у вас много — всё собирать ручками занятие не благородное. Более того, статика вообще может лежать какой-нибудь CDN (Content Delivery Network — сеть доставки контента) по типу Amazon S3.

В текущих реалиях в Django мы имеем два «вида» статики:

  1. Специфичная для приложения, которая, по-хорошему, должна лежать внутри этого приложения в папке static, желательно даже ещё глубже: «/static//» дабы исключить вероятность пересечения путей файлов с другими приложениями.
  2. Специфичная для проекта статика. Для неё можно создать папку в корне, в примерах назовём эту папку assets.

Первым пунктом можно пренебречь и хранить всё на уровне проекта, если вы не планируете делать переносимое приложение («reusable»), тут есть как плюсы: всё в одном месте, так и минусы: если вы захотите убрать приложение, может потребоваться больше усилий, либо, на больших проектах, это может создать кашу.

При таком подходе настройки STATIC_ROOT и STATICFILES_DIRS должны указывать на следующее:

  • STATIC_ROOT — указывает на изначально пустую папку, в которую будет собрана вся статика: как project-wide, так и app-specific. Эту папку, в общем случае, должен обслуживать frontend web-сервер (например, nginx).
  • STATICFILES_DIRS — должна содержать путь до assets:
    STATICFILES_DIRS = (‘/path/to/assets/’, )

После этого на боевом сервере (читай «DEBUG = False») перед развёртыванием приложения надо выполнить команду:

Которая соберёт все файлы в папку STATIC_ROOT.

Для dev-сервера Django (т.е. если вы используете команду «python manage.py runserver» для разработки) настройка статики закончена и запускать команду collectstatic не обязательно — статика будет подцеплена автоматом. Однако, если вы используете другой сервер для разработки, то вы можете заставить Django обрабатывать статику добавив немного «магии» в ваш urls.py. Также в urls.py надо будет добавить URL для медиа-файлов. Итак, вот фрагменты файла настроек settings.py:
# эта переменная будет указывать на папку проекта

А вот содержимое urls.py:

Напоследок, хочу заметить, что некоторые описанные детали справедливы только для общего случая. Рекомендую также прочитать официальную документацию Django.

Понравилась статья? Поделиться с друзьями:
Комментариев: 2
  1. baloon

    Спасибо большое. Кратко и по делу)). Помогло немного разобраться.

    Только для Django 1.5 путь для staticfiles_urlpatterns() немного другой:

    from django.contrib.staticfiles.urls import staticfiles_urlpatterns

    # … the rest of your URLconf here …

    urlpatterns += staticfiles_urlpatterns()

    http://www.djbook.ru/rel1.5/ref/contrib/staticfiles.html?highlight=staticfiles_urlpatterns#django.contrib.staticfiles.templatetags.staticfiles.django.contrib.staticfiles.urls.staticfi

    1. lizz

      Спасибо за уточнение, поправим пост.

Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: