Django на хостинге не видит static файлы

Обновлено: 06.07.2024

Веб-сайты обычно должны обслуживать дополнительные файлы, такие как изображения, 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.

enter image description here





так в nginx конфиге пропиши путь просто

Так прописан вроде (пункт 6 в моей инструкции):



root на alias попробуйте поменять.
Или /static/ в конце пути сотрите.

Обновлено 8 Окт. 2015, 22:29 lampslave.

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 .

Используйте любой веб-сервер для обслуживания файлов. Развертывание статических файлов обсуждает некоторые часто используемые стратегии развертывания статических файлов.

Читайте также: