Django на хостинге не видит static файлы
Веб-сайты обычно должны обслуживать дополнительные файлы, такие как изображения, JavaScript или CSS. В Django эти файлы называются «статическими файлами». Django предоставляет django.contrib.staticfiles помощь в этом управлении.
На этой странице рассказывается, как обслуживать эти статические файлы.
Настройка статических файлов ¶
Убедитесь, что django.contrib.staticfiles это включено в вашу настройку INSTALLED_APPS .
В вашем файле настроек определите STATIC_URL , например:
В своих шаблонах используйте тег шаблона static для создания URL-адреса заданного относительного пути с использованием STATICFILES_STORAGE настроенного хранилища .
Храните свои статические файлы в папке, названной static в вашем приложении. Например, mon_app/static/mon_app/exemple.jpg .
В дополнение к этим шагам настройки вам также потребуется обслуживать статические файлы.
Во время разработки, если вы используете django.contrib.staticfiles , статические файлы автоматически обслуживаются, runserver если для DEBUG него установлено значение True (см. django.contrib.staticfiles.views.serve() ).
Этот метод заведомо неэффективен и, вероятно, небезопасен , поэтому его нельзя использовать в производственной среде .
См. Раздел « Развертывание статических файлов» для получения истинных стратегий службы статических файлов в производственных средах.
В вашем проекте, вероятно, также будут статические элементы, не связанные с конкретным приложением. Помимо использования каталога static/ в ваших приложениях, вы можете определить список каталогов ( STATICFILES_DIRS ) в файле настроек, сообщающий Django, где он может найти другие статические файлы. Например :
См. Документацию STATICFILES_FINDERS по настройке, чтобы узнать, как staticfiles искать файлы.
Пространства имен статических файлов
Мы могли бы проще помещать наши статические файлы напрямую my_app/static (вместо создания подкаталога my_app ), но это было бы плохой идеей. Django выбирает первый статический файл, соответствующий поисковому имени, и если бы у вас был файл с таким же именем в другом приложении, Django не смог бы отличить их друг от друга. Нам нужно указать Django правильный файл, и лучший способ убедиться в этом - использовать пространства имен . То есть, поместив эти статические файлы в другой подкаталог, названный в честь приложения.
В STATICFILES_DIRS , можно указать пространства имен с помощью префиксов .
Сервис статических файлов в разработке ¶
Если вы используете, django.contrib.staticfiles как описано выше, runserver автоматически делает это, если DEBUG установлено значение True . Если django.contrib.staticfiles нет INSTALLED_APPS , вы все равно можете обслуживать статические файлы вручную с помощью представления django.views.static.serve() .
Однако в производстве это недопустимо! Вы можете просмотреть некоторые распространенные стратегии развертывания в разделе «Развертывание статических файлов» .
Например, если параметр STATIC_URL определен как /static/ , вы можете настроить эту службу, добавив в файл следующий фрагмент кода urls.py :
Кроме того, эта служебная функция работает только с самим файлом STATIC_ROOT ; он не выполняет обнаружение статических файлов, как это делает django.contrib.staticfiles .
Сервис файлов, загружаемых пользователями в процессе разработки ¶
Во время разработки вы можете обслуживать файлы, загруженные MEDIA_ROOT пользователями, используя представление django.views.static.serve() .
Однако в производстве это недопустимо! Вы можете просмотреть некоторые распространенные стратегии развертывания в разделе «Развертывание статических файлов» .
Например, если параметр MEDIA_URL определен как /media/ , вы можете настроить эту службу, добавив в файл следующий фрагмент кода urls.py :
Тесты ¶
По этой причине он staticfiles поставляется со своим собственным классом django.contrib.staticfiles.testing.StaticLiveServerTestCase , подклассом предыдущего, который имеет возможность прозрачно обслуживать все статические файлы при запуске этих тестов, что очень похоже на то, что мы мы получаем во время разработки , то есть без необходимости собирать их при первом использовании . DEBUG = True collectstatic
Развертывание ¶
django.contrib.staticfiles предоставляет удобную команду управления для сбора статических файлов в один каталог для упрощения обслуживания.
Задайте настройку STATIC_ROOT в соответствии с каталогом, из которого вы хотите обслуживать файлы, например:
Запустите команду управления collectstatic :
Это скопирует все файлы из ваших статических папок с файлами в каталог STATIC_ROOT .
Используйте любой веб-сервер для обслуживания файлов. Развертывание статических файлов обсуждает некоторые часто используемые стратегии развертывания статических файлов.
Здравствуйте. Изучаю Django. Вернее пытаюсь, так как поднять по-человечески сервер на локальном компьютере с Ubuntu не получается.
Скомпоновал для себя инструкцию из нескольких. Основную часть взял с Djbook.
Но остается у меня проблема: сервер после начальной настройки (и команды ./manage.py collectstatic ) не видит статические файлы. Даже на странице входа в админку (localhost:8000/admin)не отображаются стили. Я уже не говорю про статические файлы в папке "static" приложений.
Очень прошу помощи. Мучусь 3 день. Ресурс моего SSD скоро закончится от переустановок OS.
так в nginx конфиге пропиши путь просто
Так прописан вроде (пункт 6 в моей инструкции):
root на alias попробуйте поменять.
Или /static/ в конце пути сотрите.
root на alias попробуйте поменять.
Или /static/ в конце пути сотрите.
Пробовал раньше уже эти варианты. Попробовал сейчас еще раз. А после изменения кода нужно писать какие-то команды перезагрузки чего-то? Например, nginx?
Хотя я на всякий случай все равно перезагрузил, но НЕ ПОМОГАЕТ.
Потом сделайте collectstatic и перезапустите django и nginx.
И ещё. У nginx есть доступ в /home/admin1 ?
Обновлено 8 Окт. 2015, 23:05 lampslave.1)По фрагменту кода я понял, что строку STATIC_ROOT = '/home/admin1/myenv/myproject/static' нужно было попробовать добавить в файл настроек Nginx?
Добавил так, как Вы указали. Nginx с этой строкой в файле не захотел перезагружаться. Выдал ошибку.
2)А как проверить, есть ли у Nginx права? Я знаю, как смотреть просто права на папку.
Вот последняя строка из "access_log":
Последняя строка из "error_log":
Разумеется нет, это же джанговский параметр. В настройках обновите.
Хм, по идее, x должно быть достаточно. Покажите ещё права на вложенные каталоги, по порядку.
А, ну правильно. Вам в /home/admin1/myenv/myproject/static/static/admin/css/login.css ничего лишнего в глаза не бросается? Сдаётся мне, что вы так и оставили свой кривой вариант
Бли-и-и-и-ин. Нашел. В настройках Nginx нужно было указать не:
В логе ошибок уведел, что не по тому адресу обращается.
Пока что заработало. Самое интересное, что в инструкции на Djbook в первом посте правильно написано, а внизу есть "обновление", где указано лишнее "static", из-за чего и получилась ошибка.
Большое спасибо за помощь. Надеюсь, проблема решилась.
Самое интересное, что в инструкции на Djbook в первом посте правильно написано, а внизу есть "обновление", где указано лишнее "static", из-за чего и получилась ошибка.
Это где такое? Прямую ссылку дайте, исправим.
Если ничего не помогает, прочтите документацию, наконец!Это где такое? Прямую ссылку дайте, исправим.
В этом посте прямо жирным выделено "static".
root на alias попробуйте поменять.
Или /static/ в конце пути сотрите.
А ведь сразу этот вариант предложили. Наверное я второе и не попробовал сделать.
Там alias , так что всё правильно. Алиас указывает на папку напрямую, а рут указывает на родителя.
Мой вам большой совет. Когда что-то идёт не так, не надо кидаться гуглить море инструкций, чего-то там шаманить, менять по 20 раз. Надо отдохнуть, взять себя в руки и, если во время отдыха не родилась здравая мысль, последовать совету в подписи RaD-а. Читать всю документацию от корки до корки не обязательно, но изучить то, что вы уже добавили в конфиг, стоит точно. Знаю, этому совету, сложно следовать (частенько сам не могу себя заставить это сделать), но попробовать стоит :)
Там alias, так что всё правильно. Алиас указывает на папку напрямую, а рут указывает на родителя.
Тогда я вдвойне осёл.
Просто делал все "методом тыка" и не понимал, в какой ситуации ждать изменений.
Просто делал все "методом тыка" и не понимал, в какой ситуации ждать изменений.
См. мой предыдущий пост, я там кое-что добавил :)
См. мой предыдущий пост, я там кое-что добавил :)
У меня сложно с английским. Обычно это указываю. В этот раз забыл.
И самое обидное, что я сталкивался с инструкциями, где было указано "alias" и я пробовал менять, но не знал, что действие наступает именно после ручной перезагрузки "Nginx".
Я пытаюсь обслуживать статические файлы в своей среде разработки Django 1.3.
Вот мои настройки
Мой каталог / home / glide / Documents / django / cbox / static / похож на
Нужно ли указывать шаблоны для css, javascript и изображений отдельно?
Я перепутал STATIC_ROOT и STATICFILES_DIRS
На самом деле я не совсем понимал полезность STATIC_ROOT . Я думал, что это каталог, в который я должен поместить свои общие файлы. Этот каталог используется для производства, это каталог, в который статические файлы будут помещаться (собираться) с помощью collectstatic .
STATICFILES_DIRS - это тот, который мне нужен.
Поскольку я нахожусь в среде разработки, решение для меня - не использовать STATIC_ROOT (или указать другой путь) и установить каталог общих файлов в STATICFILES_DIRS :
Также не забудьте from django.conf import settings
Н.О. urls.py должно быть , как в вопросе ( то же самое для СМИ) , и не забудьте from django.conf import settings , конечно Я просто хочу добавить к этому ответу, не пропустите s. это должно быть STATICFILES_DIRS. Я сделал STATICFILE_DIRS, свел с ума 45 минут в поисках ошибки. Я использую BASE_DIR встроенную const вместо, SITE_ROOT и она работает.Может быть только две вещи в settings.py которые вызывают у вас проблемы.
1) STATIC_URL = '/static/'
и ваши статические файлы должны находиться в статическом каталоге, который находится в том же каталоге, что и файл настроек проекта.
Даже если ваши статические файлы не загружаются, причина в том, что вы могли сохранить
измените его на True (только для разработки). При производстве просто измените STATICFILES_DIRS путь, по которому находятся статические файлы.
В моем случае это была ложная переменная среды для отладки. Я установил его в значение true, и теперь он работает Привет .. Я пробовал все упомянутые решения, но он все равно дает 404. Кто-нибудь может помочь с этим, пожалуйста?Обслуживать статические файлы можно несколькими способами; вот мои заметки к себе:
- добавить static/my_app/ каталог в my_app (см. примечание о пространстве имен ниже)
- определить новый каталог верхнего уровня и добавить его в STATICFILES_DIRS в settings.py (обратите внимание на это The STATICFILES_DIRS setting should not contain the STATIC_ROOT setting )
Я предпочитаю первый способ и настройку, которая близка к способу, определенному в документации , поэтому для того, чтобы обслужить файл admin-custom.css для переопределения нескольких стилей администратора, у меня есть такая настройка:
Затем это используется в шаблоне следующим образом:
При развертывании я запускаю collectstatic и обслуживаю статические файлы с помощью nginx.
Веб-сайты обычно должны обслуживать дополнительные файлы, такие как изображения, JavaScript или CSS. В Django эти файлы называются «статическими файлами». Django предоставляет django.contrib.staticfiles помощь в этом управлении.
На этой странице рассказывается, как обслуживать эти статические файлы.
Настройка статических файлов ¶
Убедитесь, что django.contrib.staticfiles это включено в вашу настройку INSTALLED_APPS .
В вашем файле настроек определите STATIC_URL , например:
В своих шаблонах используйте тег шаблона static для создания URL-адреса заданного относительного пути с использованием STATICFILES_STORAGE настроенного хранилища .
Храните свои статические файлы в папке, названной static в вашем приложении. Например, mon_app/static/mon_app/exemple.jpg .
В дополнение к этим шагам настройки вам также потребуется обслуживать статические файлы.
Во время разработки, если вы используете django.contrib.staticfiles , статические файлы автоматически обслуживаются, runserver если для DEBUG него установлено значение True (см. django.contrib.staticfiles.views.serve() ).
Этот метод заведомо неэффективен и, вероятно, небезопасен , поэтому его нельзя использовать в производственной среде .
См. Раздел « Развертывание статических файлов» для получения истинных стратегий службы статических файлов в производственных средах.
В вашем проекте, вероятно, также будут статические элементы, не связанные с конкретным приложением. Помимо использования каталога static/ в ваших приложениях, вы можете определить список каталогов ( STATICFILES_DIRS ) в файле настроек, сообщающий Django, где он может найти другие статические файлы. Например :
См. Документацию STATICFILES_FINDERS по настройке, чтобы узнать, как staticfiles искать файлы.
Пространства имен статических файлов
Мы могли бы проще помещать наши статические файлы напрямую my_app/static (вместо создания подкаталога my_app ), но это было бы плохой идеей. Django выбирает первый статический файл, соответствующий поисковому имени, и если бы у вас был файл с таким же именем в другом приложении, Django не смог бы отличить их друг от друга. Нам нужно указать Django правильный файл, и лучший способ убедиться в этом - использовать пространства имен . То есть, поместив эти статические файлы в другой подкаталог, названный в честь приложения.
В STATICFILES_DIRS , можно указать пространства имен с помощью префиксов .
Сервис статических файлов в разработке ¶
Если вы используете, django.contrib.staticfiles как описано выше, runserver автоматически делает это, если DEBUG установлено значение True . Если django.contrib.staticfiles нет INSTALLED_APPS , вы все равно можете обслуживать статические файлы вручную с помощью представления django.views.static.serve() .
Однако в производстве это недопустимо! Вы можете просмотреть некоторые распространенные стратегии развертывания в разделе «Развертывание статических файлов» .
Например, если параметр STATIC_URL определен как /static/ , вы можете настроить эту службу, добавив в файл следующий фрагмент кода urls.py :
Кроме того, эта служебная функция работает только с самим файлом STATIC_ROOT ; он не выполняет обнаружение статических файлов, как это делает django.contrib.staticfiles .
Сервис файлов, загружаемых пользователями в процессе разработки ¶
Во время разработки вы можете обслуживать файлы, загруженные MEDIA_ROOT пользователями, используя представление django.views.static.serve() .
Однако в производстве это недопустимо! Вы можете просмотреть некоторые распространенные стратегии развертывания в разделе «Развертывание статических файлов» .
Например, если параметр MEDIA_URL определен как /media/ , вы можете настроить эту службу, добавив в файл следующий фрагмент кода urls.py :
Тесты ¶
По этой причине он staticfiles поставляется со своим собственным классом django.contrib.staticfiles.testing.StaticLiveServerTestCase , подклассом предыдущего, который имеет возможность прозрачно обслуживать все статические файлы при запуске этих тестов, что очень похоже на то, что мы мы получаем во время разработки , то есть без необходимости собирать их при первом использовании . DEBUG = True collectstatic
Развертывание ¶
django.contrib.staticfiles предоставляет удобную команду управления для сбора статических файлов в один каталог для упрощения обслуживания.
Задайте настройку STATIC_ROOT в соответствии с каталогом, из которого вы хотите обслуживать файлы, например:
Запустите команду управления collectstatic :
Это скопирует все файлы из ваших статических папок с файлами в каталог STATIC_ROOT .
Используйте любой веб-сервер для обслуживания файлов. Развертывание статических файлов обсуждает некоторые часто используемые стратегии развертывания статических файлов.
Читайте также: