Обслуживание статических носителей при разработке Django: почему не MEDIA_ROOT? - PullRequest
21 голосов
/ 10 февраля 2010

Я прочитал это руководство об обслуживании статических носителей с Django во время разработки.

Я заметил, что MEDIA_URL и MEDIA_ROOT не использовались в этом. Зачем? Какая разница?

Я попытался сделать это с MEDIA_URL и MEDIA_ROOT, и получил странные результаты.

Ответы [ 3 ]

28 голосов
/ 10 февраля 2010

В производственной ситуации вы хотите, чтобы ваши носители обслуживались с вашего интерфейсного веб-сервера (Apache, Nginx и т. П.), Чтобы избежать дополнительной нагрузки на процесс Django / Python. Для этого обычно используются MEDIA_URL и MEDIA_ROOT.

При запуске встроенного сервера разработки вам нужно будет указать правильный URL-адрес в файле url.py - обычно я использую что-то вроде этого:

from django.conf import settings

urlpatterns += patterns('',
    (r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT}),
)

, который выбирает MEDIA_ROOT из вашего файла настроек, что означает, что он работает для разработки и в реальном времени.

21 голосов
/ 10 февраля 2010

Прямо из комментариев в settings.py ...

MEDIA_ROOT

MEDIA_ROOT - это абсолютный путь к каталогу, в котором хранятся носители, например /home/media/media.lawrence.com/.

MEDIA_URL

MEDIA_URL - это URL-адрес, который обрабатывает носитель, передаваемый с MEDIA_ROOT. Обязательно используйте косую черту, если есть компонент пути (необязательно в других случаях). Примеры: "http://media.lawrence.com"," http://example.com/media/".

Итак, чтобы перефразировать их ... MEDIA_ROOT - это место, где файлы физически хранятся в вашей системе, а MEDIA_URL - место, где эти файлы отображаются. В процессе разработки это не всегда может быть доступно, и в большинстве случаев ваша среда разработки и производственная среда не совпадают, и вам придется вернуться и измениться. Другое дело, что это НЕ ХОРОШАЯ ПРАКТИКА, когда Django был разработан, чтобы НЕ показывать вам статический контент.

Если вы собираетесь использовать это в разработке, я предлагаю вам использовать метод , ограничив его до DEBUG = True . Говорить Django об обслуживании статического контента из временного местоположения во время разработки, когда для DEBUG установлено значение True, - гораздо более эффективная и безопасная практика. Вы НЕ собираетесь запускать свой сайт с включенным DEBUG, верно? Ну, по крайней мере, ты не должен.

Вот как я это реализовал:

settings.py:

STATIC_DOC_ROOT = os.path.join(os.getcwd(), 'site_media')

urls.py:

from django.conf import settings
## debug stuff to serve static media
if settings.DEBUG:
    urlpatterns += patterns('',
        (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', 
            {'document_root': settings.STATIC_DOC_ROOT}),
   )

Таким образом, в любом проекте, над которым я работаю, есть каталог site_media со всеми необходимыми носителями. В dev он самодостаточен, и мне не нужно переключать биты в настройках, кроме DEBUG, что я и делал бы в любом случае.

11 голосов
/ 19 июля 2016

Django docs рекомендует следующий подход, который я изменил для моего варианта использования:

urlpatterns = [
    # url patterns
]

from django.conf import settings

if settings.DEBUG:
    from django.conf.urls.static import static
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Примечание: вышеизложенное предполагает, что вы правильно установили MEDIA_URL и MEDIA_ROOT

... а вот djangodocs linkslap .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...