Блог

Главная - Вопросы по программированию - Значение Django STATIC_URL не распознано в рабочей среде

Значение Django STATIC_URL не распознано в рабочей среде

#django #apache #mod-wsgi

#django #apache #мод-wsgi

Вопрос:

Я пытаюсь развернуть свое приложение Django в рабочей среде с помощью Apache mod_wsgi, но сталкиваюсь с проблемами со статическими файлами. По какой-то причине {{ STATIC_URL }} не распознается моими шаблонами в рабочей среде. В процессе разработки мои статические файлы имеют URL:

 <script type="text/javascript" src="/static/js/myfile.js"></script>

но в рабочей среде URL является:

 <script type="text/javascript" src="js/myfile.js"></script>

Когда я пытаюсь распечатать {{STATIC_URL}} , в рабочей среде оно пустое. Чего мне здесь не хватает?

Спасибо!

Комментарии:

1. Прежде всего рекомендуется начинать строку для STATIC_URL настройки с косой черты: /static/ вместо static/ . Однако это, вероятно, не решит вашу проблему. Для чего это написано STATIC_URL в вашем settings.py ? Можете ли вы проверить работоспособность с помощью python manage.py shell -> from django.conf import settings -> print settings.STATIC_URL . Что это говорит?

2. Спасибо за ваш ответ! Я только что проверил, и у меня действительно есть косая черта в моем settings.py для /static/ . Извините, я просто ввел код из памяти. Под «производственной» я просто имел в виду мою локальную установку Apache mod-wsgi. Когда я выполняю запрошенную вами команду оболочки, я получил /static/ то, что ожидалось. Чтобы уточнить, моя разработка и производство прямо сейчас находятся на одном компьютере. Разработчик использует manage.py runserver , а в рабочей среде используется Apache mod-wsgi. Спасибо!

3. Хорошо, интересно. Вы ввели 'django.core.context_processors.static' свои TEMPLATE_CONTEXT_PROCESSORS настройки? Это становится {{STATIC_URL}} доступным в ваших шаблонах при визуализации с помощью RequestContext в ваших представлениях. Хотя, если оно показывает это в dev, но не в production, я думаю, вы это сделали. Прямо сейчас у меня нет другого объяснения для этого.

4. Да, у меня есть эта строка в моем контекстном процессоре. Спасибо за вашу помощь 🙂 У кого-нибудь еще есть другие идеи?

5. Вы перезапустили сервер или touch файл wsgi? Не могу придумать ничего другого на основе этих комментариев.

Ответ №1:

Просто наткнулся на это, пытаясь решить эту проблему самостоятельно. Ключевым шагом для меня было то, что моим представлениям передавался Context , а не RequestContext объект. Чтобы решить эту проблему, где я использовал render_to_response метод, мне пришлось предоставить следующий третий параметр:

 context_instance=RequestContext(request)

Ваша проблема, очевидно, была решена, но это на тот случай, если кто-то другой столкнется с такой же проблемой.

Комментарии:

1. Вы знаете, почему именно это? На сервере разработки я его не видел, только в рабочей среде. Что такого в django.core.context_processors.static, что отличается в Apache mod_wsgi?

Ответ №2:

Использует ли mod_wsgi тот же python, что и ваша оболочка? И тот же PYTHONPATH?

Я предлагаю попробовать другой веб-сервер, просто чтобы узнать, является ли это проблемой mod_wsgi или это проблема с вашей настройкой / средой. Gunicorn очень прост в настройке. Чтобы использовать его:

  • pip install gunicorn
  • добавьте gunicorn в ваши INSTALLED_APPS
  • запустите рабочий сервер с ./manage.py run_gunicorn

Комментарии:

1. Я попробую это. Спасибо. В итоге я просто перезапустил всю свою чертову машину, и это исправило.

2. вероятно, PYTHONPATH, отображаемый mod_wsgi, не был обновлен.