Настройка и подключение статических файлов в Django
Если вы искали способ добавить изображения, стили и js в свой проект на Django, то пришли по адресу.
Что такое статические файлы в Django?
Изображения, JS и CSS-файлы называются статическими файлами или ассетами проекта Django.
1. Создадим папку для статических файлов
В папке проекта Django создайте новую папку «static». В примере выше она находится в директории «dstatic».
2. Укажите статический URL Django в настройках
Теперь убедитесь, что статические файлы Django django.contrib.staticfiles указаны в списке установленных приложений в settings.py.
Они должны быть там по умолчанию.
После этого пролистайте в нижнюю часть файла настроек и укажите статический URL, если такого еще нет. Вы также можете указать статическую папку, чтобы Django знал, где искать статические файлы.
Не забудьте импортировать библиотеку os после добавления кода выше.
После завершения базовой настройки рассмотрим, как добавлять и показывать изображения в шаблонах, а также как подключить свои JavaScript и CSS файлы.
3. Создайте папку для изображений
Создайте папку в «static» специально для изображений. Назовите ее «img». Главное после этого правильно ссылаться на нее в шаблонах.
4. Загрузите статический файл в свой HTML-шаблон
Теперь в выбранном шаблоне (например, в «home.html») загрузите статический файл в верхней части страницы.
Важно добавить <% load static %>до того, как добавлять изображение. В противном случае оно не будет загружено.
Использование тега static в шаблоне
После этого вы можете использовать тег «static» в шаблоне для работы с источником изображения.
Documentation
Managing static files (e.g. images, JavaScript, CSS)¶
Websites generally need to serve additional files such as images, JavaScript, or CSS. In Django, we refer to these files as “static files”. Django provides django.contrib.staticfiles to help you manage them.
This page describes how you can serve these static files.
Configuring static files¶
In addition to these configuration steps, you’ll also need to actually serve the static files.
This method is grossly inefficient and probably insecure, so it is unsuitable for production.
See Deploying static files for proper strategies to serve static files in production environments.
Your project will probably also have static assets that aren’t tied to a particular app. In addition to using a static/ directory inside your apps, you can define a list of directories ( STATICFILES_DIRS ) in your settings file where Django will also look for static files. For example:
See the documentation for the STATICFILES_FINDERS setting for details on how staticfiles finds your files.
Static file namespacing
Now we might be able to get away with putting our static files directly in my_app/static/ (rather than creating another my_app subdirectory), but it would actually be a bad idea. Django will use the first static file it finds whose name matches, and if you had a static file with the same name in a different application, Django would be unable to distinguish between them. We need to be able to point Django at the right one, and the best way to ensure this is by namespacing them. That is, by putting those static files inside another directory named for the application itself.
Serving static files during development¶
This helper function works only in debug mode and only if the given prefix is local (e.g. /static/ ) and not a URL (e.g. http://static.example.com/ ).
Serving files uploaded by a user during development¶
During development, you can serve user-uploaded media files from MEDIA_ROOT using the django.views.static.serve() view.
This helper function works only in debug mode and only if the given prefix is local (e.g. /media/ ) and not a URL (e.g. http://media.example.com/ ).
Testing¶
Deployment¶
django.contrib.staticfiles provides a convenience management command for gathering static files in a single directory so you can serve them easily.
Set the STATIC_ROOT setting to the directory from which you’d like to serve these files, for example:
Run the collectstatic management command:
This will copy all files from your static folders into the STATIC_ROOT directory.
Use a web server of your choice to serve the files. Deploying static files covers some common deployment strategies for static files.
Управление статическими файлами (например, изображениями, JavaScript, CSS) ¶
Веб-сайты обычно должны обслуживать дополнительные файлы, такие как изображения, JavaScript или CSS. В Django мы называем эти файлы «статическими файлами». Django предоставляет django.contrib.staticfiles помощь в управлении ими.
На этой странице описывается, как вы можете обслуживать эти статические файлы.
Настройка статических файлов ¶
В дополнение к этим шагам настройки вам также необходимо будет обслуживать статические файлы.
См. Раздел Развертывание статических файлов для получения информации о правильных стратегиях обслуживания статических файлов в производственных средах.
В вашем проекте, вероятно, также будут статические активы, не привязанные к конкретному приложению. Помимо использования static/ каталога внутри ваших приложений, вы можете определить список каталогов ( STATICFILES_DIRS ) в вашем файле настроек, где Django также будет искать статические файлы. Например:
См. Документацию по STATICFILES_FINDERS настройке для получения подробной информации о том, как staticfiles находить ваши файлы.
Статическое пространство имен файлов
Обслуживание статических файлов во время разработки ¶
Эта вспомогательная функция работает только в режиме отладки и только в том случае, если данный префикс является локальным (например /static/ ), а не URL-адресом (например http://static.example.com/ ).
Обслуживание файлов, загруженных пользователем во время разработки ¶
Во время разработки вы можете обслуживать загруженные пользователем медиафайлы с MEDIA_ROOT помощью django.views.static.serve() представления.
Эта вспомогательная функция работает только в режиме отладки и только в том случае, если данный префикс является локальным (например /media/ ), а не URL-адресом (например http://media.example.com/ ).
Тестирование ¶
Развертывание ¶
django.contrib.staticfiles предоставляет удобную команду управления для сбора статических файлов в одном каталоге, чтобы вы могли легко их обслуживать.
Задайте STATIC_ROOT настройку для каталога, из которого вы хотите обслуживать эти файлы, например:
Запустите команду collectstatic управления:
Это скопирует все файлы из ваших статических папок в STATIC_ROOT каталог.
Используйте любой веб-сервер для обслуживания файлов. Развертывание статических файлов охватывает некоторые общие стратегии развертывания статических файлов.
Документация Django 1.6
Этот раздел описывает как работать с ними.
Настройка статики¶
Кроме конфигурации, необходимо настроить раздачу статических файлов.
Потому что это представление очень неэффективно и, возможно, небезопасно. Оно предназначено только для разработки, и не должно использоваться на боевом сервере.
Способы раздачи статических файлов описаны в разделе Развертывание статических файлов.
Static file namespacing
Вы можете добавлять статические файлы непосредственно в каталог my_app/static/ (не создавая подкаталог my_app ), но это плохая идея. Django использует первый найденный по имени файл и, если у вас есть файлы с одинаковым названием в разных приложениях, Django не сможет использовать оба. Необходимо как-то указать, какой файл использовать, и самый простой способ – это пространство имен. Просто положите их в каталог с названием приложения( my_app/static/my_app ).
Раздача статических файлов при разработке.¶
Не используйте его на боевом сервере! Способы раздачи статических файлов описаны в разделе Развертывание статических файлов.
Это представление работает только при включенной отладке и для локальных префиксов (например /static/ ), а не полных URL-ов (e.g. http://static.example.com/ ).
Раздача файлов, загруженных пользователем, при разработке¶
Не используйте его на боевом сервере! Способы раздачи статических файлов описаны в разделе Развертывание статических файлов.
Это представление работает только при включенной отладке и для локальных префиксов (например /media/ ), а не полных URL-ов (e.g. http://media.example.com/ ).
Развертывание¶
Используйте любой веб-сервер для раздачи этих файлов. Способы раздачи статических файлов описаны в разделе Развертывание статических файлов.
Documentation
Deploying static files¶
Serving static files in production¶
As with all deployment tasks, the devil’s in the details. Every production setup will be a bit different, so you’ll need to adapt the basic outline to fit your needs. Below are a few common patterns that might help.
Serving the site and your static files from the same server¶
If you want to serve your static files from the same server that’s already serving your site, the process may look something like:
You’ll probably want to automate this process, especially if you’ve got multiple web servers.
Serving static files from a dedicated server¶
Most larger Django sites use a separate Web server – i.e., one that’s not also running Django – for serving static files. This server often runs a different type of web server – faster but less full-featured. Some common choices are:
Configuring these servers is out of scope of this document; check each server’s respective documentation for instructions.
Since your static file server won’t be running Django, you’ll need to modify the deployment strategy to look something like:
Serving static files from a cloud service or CDN¶
Another common tactic is to serve static files from a cloud storage provider like Amazon’s S3 and/or a CDN (content delivery network). This lets you ignore the problems of serving static files and can often make for faster-loading Web pages (especially when using a CDN).
When using these services, the basic workflow would look a bit like the above, except that instead of using rsync to transfer your static files to the server you’d need to transfer the static files to the storage provider or CDN.
There’s any number of ways you might do this, but if the provider has an API, you can use a custom file storage backend to integrate the CDN with your Django project. If you’ve written or are using a 3rd party custom storage backend, you can tell collectstatic to use it by setting STATICFILES_STORAGE to the storage engine.
For example, if you’ve written an S3 storage backend in myproject.storage.S3Storage you could use it with:
Once that’s done, all you have to do is run collectstatic and your static files would be pushed through your storage package up to S3. If you later needed to switch to a different storage provider, you may only have to change your STATICFILES_STORAGE setting.