Подключение статических файлов. Фильтры шаблонов
На предыдущем занятии мы в целом познакомились с шаблонами в Django. Продолжим эту тему и следующий важный шаг – это научиться подключать к шаблонам статические файлы, например, оформление CSS или JavaScript и так далее. Здесь есть свои тонкости. Как мы помним, наше приложение может работать в двух режимах: отладки – на тестовом веб-сервере; эксплуатации – на реальном веб-сервере. Так вот, в режиме отладки статические файлы Django ищет во всех каталогах static приложений и во всех возможных каталогах static внешних модулей (например, админки). То есть, статические файлы при отладке совершенно спокойно можно размещать в подкаталоге static нашего приложения. Но, в режиме эксплуатации реальный веб-сервер будет брать все статические файлы из папки static, расположенной в каталоге всего проекта. Но как появится такая папка со всеми необходимыми файлами? Для этого, при подготовке проекта к эксплуатации, выполняется специальная команда фреймворка Django:
python manage.py collectstatic
которая собирает все статические файлы из разных приложений и модулей и помещает в одну общую папку проекта.

- STATIC_URL – префикс URL-адреса для статических файлов;
- STATIC_ROOT – путь к общей статической папке, используемой реальным веб-сервером;
- STATICFILES_DIRS – список дополнительных (нестандартных) путей к статическим файлам, используемых для сбора и для режима отладки.
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
Наконец, при необходимости, можем определить третью константу со списком нестандартных путей, где также могут располагаться статические файлы:
STATICFILES_DIRS = []
В нашем случае таких путей нет, поэтому список пуст. Давайте теперь создадим папку static в нашем приложении women и, также как и для шаблонов, укажем в ней вложенный каталог women, чтобы не было конфликтов имен между статическими файлами разных модулей и приложений. (В действительности, Django просто найдет первый подходящий файл и на этом остановится. Чтобы этот файл был тем, что нам нужен, как раз и используется дополнительный каталог, который играет роль некоторого пространства имен.) В этом последнем подкаталоге уже будем размещать файлы css – для файлов CSS; js – для файлов JavaScript; images – для общих файлов изображений и так далее. Я создам подкаталог css для файла стилей нашего сайта. И в нем размещу файл styles.css, который заготовил заранее, чтобы не отвлекаться на CSS-оформление сайта, а сосредоточится на изучении фреймворка Django. Вы сможете скачать весь этот проект с github и, при необходимости, внимательно его изучить. Также создам подкаталог images и скопирую в него все необходимые изображения для базового оформления сайта. Все, подготовительная часть завершена. Теперь мы можем использовать эти внешние файлы в шаблонах нашего приложения. Для этого используется специальный тег static, который сначала подключается в шаблоне:
{% load static %}
А, затем, для формирования URL к тому или иному статическому файлу, используется конструкция: <% static ' <путь к файлу от папки static>‘ %> Например, для подключения css-файла в базовом шаблоне base.html, следует прописать:%>
link type="text/css" href="" rel="stylesheet" />

При просмотре страницы увидим следующий URL-адрес: И, щелкнув по нему, убеждаемся, что он успешно загружается. Отлично, это мы сделали. Далее, я возьму заготовленные html-файлы для базового шаблона страниц (base.html) и главной страницы (index.html). Для более детального ознакомления вы сможете их скачать по ссылке с github. Также я добавил в БД знаменитых женщин и их биографии. Сделал это с помощью SQLiteStudio. После всех этих изменений главная страница сайта выглядит так: Конечно, вы можете использовать свои шаблоны, принципиального значения это не будет иметь. Часто для оформления сайтов используют онлайн-сервисы. Наиболее известный из них https://getbootstrap.com Но я намеренно не стал к нему обращаться, чтобы не усложнять изложение материала по Django. Итак, на нашем сайте выводится пока только заголовок и контент статей. Нам бы хотелось, чтобы в списке контент выводился не полностью, а фрагментом, скажем, 50 слов или 100 символов. Как это сделать? Для таких целей в шаблонах предусмотрены специальные фильтры, которые позволяют управлять фрагментами данных. Список всех фильтров можно посмотреть на странице русскоязычной документации: https://djbook.ru/rel3.0/ref/templates/builtins.html#ref-templates-builtins-filters Использовать их предельно просто. Смотрите, нам для правильного отображения страницы нужно, во-первых, проставить теги абзацев при выводе постов. Это можно сделать с помощью фильтра: <
, если строки в тексте следуют друг за другом и тег абзаца
, если между строками имеется пустая строка. Я добавлял текст в БД с пустыми строками, поэтому этот фильтр добавит теги абзацев. Конкретно, в нашем шаблоне главной страницы index.html этот фильтр запишется так:
p>{p.content}/p>
Если теперь обновить страницу, то увидим разбивку текста на абзацы. Отлично, это есть. Следующее, что нам нужно – это ограничить размер постов в списке 50-ю словами. За это отвечает фильтр: <
p>{p.content}/p>
Смотрите, здесь к контенту применяются сразу два фильтра: первый добавляет теги абзацев, а второй обрезает текст до 50 слов. То есть, мы легко можем применить к переменной множество фильтров для получения искомого результата. Обновим страницу и увидим адекватное отображение списка актрис:
По аналогии используются все остальные фильтры в шаблонах фреймворка Django. В заключение я отмечу одну важную особенность отображения информации на страницах шаблонов. Например, если в текст статьи поместить какой-либо HTML-тег, например, написать вначале в поле content «
Анджелина Джоли
», то при выводе мы увидим, что тег h1 был экранирован, то есть, заменен спецсимволами. Это намеренное поведение Django с целью защиты сайта от возможных хакерских атак. Если же нам все-таки нужно вывести статью без экранирования тегов, то можно использовать фильтр: %> контент Например, чтобы отключить экранирование, в шаблоне index.html можем указать, чтобы поле content выводилось как есть со всеми тегами:
p> {% autoescape off %} {p.content} {% endautoescape %} /p>
Обработка статических файлов (например, изображений, JavaScript, CSS) ¶
Веб-сайты обычно должны обслуживать дополнительные файлы, такие как изображения, JavaScript или CSS. В Django эти файлы называются «статическими файлами». Django предоставляет django.contrib.staticfiles помощь в этом управлении.
На этой странице рассказывается, как обслуживать эти статические файлы.
Настройка статических файлов ¶
- Убедитесь, что django.contrib.staticfiles это включено в вашу настройку INSTALLED_APPS .
- В вашем файле настроек определите STATIC_URL , например:
STATIC_URL = '/static/'
load static %> img src=" static "my_app/example.jpg" %>" alt="My image">
В дополнение к этим шагам настройки вам также потребуется обслуживать статические файлы.
Во время разработки, если вы используете django.contrib.staticfiles , статические файлы автоматически обслуживаются, runserver если для DEBUG него установлено значение True (см. django.contrib.staticfiles.views.serve() ).
Этот метод заведомо неэффективен и, вероятно, небезопасен , поэтому его нельзя использовать в производственной среде .
См. Раздел « Развертывание статических файлов» для получения истинных стратегий службы статических файлов в производственных средах.
В вашем проекте, вероятно, также будут статические элементы, не связанные с конкретным приложением. Помимо использования каталога static/ в ваших приложениях, вы можете определить список каталогов ( STATICFILES_DIRS ) в файле настроек, сообщающий Django, где он может найти другие статические файлы. Например :
STATICFILES_DIRS = [ BASE_DIR / "static", '/var/www/static/', ]
См. Документацию 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 :
from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # . the rest of your URLconf goes here . ] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)
Эта служебная функция работает только в режиме «отладки» и только если данный префикс является локальным (например /static/ ), а не URL-адресом (например http://static.example.com/ ).
Кроме того, эта служебная функция работает только с самим файлом STATIC_ROOT ; он не выполняет обнаружение статических файлов, как это делает django.contrib.staticfiles .
Сервис файлов, загружаемых пользователями в процессе разработки ¶
Во время разработки вы можете обслуживать файлы, загруженные MEDIA_ROOT пользователями, используя представление django.views.static.serve() .
Однако в производстве это недопустимо! Вы можете просмотреть некоторые распространенные стратегии развертывания в разделе «Развертывание статических файлов» .
Например, если параметр MEDIA_URL определен как /media/ , вы можете настроить эту службу, добавив в файл следующий фрагмент кода urls.py :
from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # . the rest of your URLconf goes here . ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
Эта служебная функция работает только в режиме «отладки» и только если данный префикс является локальным (например /media/ ), а не URL-адресом (например http://media.example.com/ ).
Тесты ¶
При запуске тестов, которые используют настоящий HTTP-запрос вместо встроенного тестового клиента (т. Е. С использованием LiveServerTestCase встроенного класса ), статические файлы должны обслуживаться так же, как и остальное содержимое, поэтому что тестовая среда максимально точно воспроизводит реальную среду; но LiveServerTestCase имеет только самые базовые функции для обслуживания файлов: он не знаком с функциями обнаружения файлов в приложении staticfiles и предполагает, что статический контент уже был собран в STATIC_ROOT .
По этой причине он staticfiles поставляется со своим собственным классом django.contrib.staticfiles.testing.StaticLiveServerTestCase , подклассом предыдущего, который имеет возможность прозрачно обслуживать все статические файлы при запуске этих тестов, что очень похоже на то, что мы мы получаем во время разработки , то есть без необходимости собирать их при первом использовании . DEBUG = True collectstatic
Развертывание ¶
django.contrib.staticfiles предоставляет удобную команду управления для сбора статических файлов в один каталог для упрощения обслуживания.
-
Задайте настройку STATIC_ROOT в соответствии с каталогом, из которого вы хотите обслуживать файлы, например:
STATIC_ROOT = "/var/www/example.com/static/"
$ python manage.py collectstatic
Узнать больше ¶
В этом документе описаны как основы, так и некоторые распространенные сценарии. Полную информацию обо всех настройках, командах, тегах шаблонов и других функциях django.contrib.staticfiles см. В справке по статическим файлам .
Как подключить статику в django
![]()
Django База [2023]: Подключение статики и медиа в Django ️ #5
05 января 2023
Оценки статьи
Еще никто не оценил статью
В данной статье мы добавим пути к статическим файлам, а также настроим папку media для загрузки превью для наших статей в Django 4.1.
Если вы хотите выразить благодарность автору сайта, статей и курса по Django, вы можете сделать это по ссылке ниже:
Подключение статики и медиа
Для этого нам необходимо перейти в файл конфигурации Django: settings.py и добавить следующие параметры:
backend/settings.py
STATIC_URL = '/static/' STATIC_ROOT = (BASE_DIR / 'static') MEDIA_ROOT = (BASE_DIR / 'media') MEDIA_URL = '/media/'
Статические файлы из различных пакетов и из самого Django будут загружены в папку static, находясь в режиме деплоя, это когда параметр DEBUG = False .
Для работы media в режиме DEBUG = True нам необходимо добавить следующее в backend/urls.py
backend/urls.py
"""backend URL Configuration The `urlpatterns` list routes URLs to views. For more information please see: https://docs.djangoproject.com/en/4.1/topics/http/urls/ Examples: Function views 1. Add an import: from my_app import views 2. Add a URL to urlpatterns: path('', views.home, name='home') Class-based views 1. Add an import: from other_app.views import Home 2. Add a URL to urlpatterns: path('', Home.as_view(), name='home') Including another URLconf 1. Import the include() function: from django.urls import include, path 2. Add a URL to urlpatterns: path('blog/', include('blog.urls')) """ from django.contrib import admin from django.urls import path from django.conf.urls.static import static from django.conf import settings urlpatterns = [ path('admin/', admin.site.urls), ] if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
Сохраняем, и запускаем Django для проверки: py manage.py runserver , переходим в админ.панель и в нашу добавленную статью загружаем изображение:

Отлично, теперь мы можем загружать превью к нашим статьям. Но нам нужно кое-что улучшить, а именно разложить изображения по датам, чтобы мы могли знать, в какую дату было загружено изображение на наш сайт.
Поэтому внутри модели Article, в файле modules/blog/models.py я изменю поле thumbnail с этого:
blog/models.py
class Article(models.Model): """ Модель постов для сайта """ # Другие поля. thumbnail = models.ImageField( verbose_name='Превью поста', blank=True, upload_to='images/thumbnails/', validators=[FileExtensionValidator(allowed_extensions=('png', 'jpg', 'webp', 'jpeg', 'gif'))] )
blog/models.py
class Article(models.Model): """ Модель постов для сайта """ # Другие поля. thumbnail = models.ImageField( verbose_name='Превью поста', blank=True, upload_to='images/thumbnails/%Y/%m/%d/', validators=[FileExtensionValidator(allowed_extensions=('png', 'jpg', 'webp', 'jpeg', 'gif'))] )
Добавив /%Y/%m/%d/ , это обозначнает, что мы хотим сохранить изображение в по дате, например images/thumbnails/2023/01/05 .
Я удалю загруженное изображение и добавлю новое:

Мы ещё вернемся к работе с изображениями и напишем функцию, которая будет переименовывать изображения при загрузке, а также сделаем возможность оптимизации изображения с помощью пакета Pillow.
Меню категорий
-
Загрузка категорий.
Добро пожаловать в Блог Разработчика Владислава Александровича.
Ведется медленная, но уверенная разработка функционала сайта.
Django Core: 0.3.4 / Next.js 1.0 / UPD: 05.06.2023
Статика в Django runserver
В комплект с Django входит свой веб-сервер. Запускается он командой:
$ python3 manage.py runserver
После запуска сайт будет доступен по адресу http://127.0.0.1:8000. Для лучшего понимания текста, написанного ниже, рекомендуем прочитать статью Что такое веб-сервер.
Веб-сервер runserver называют отладочным. Для “боевых” условий он решительно не годится, об этом ясно указано в документации, но зато он чрезвычайно удобен в разработке и отладке. runserver берёт на себя все обязанности сразу: и HTML генерирует, и статику отдает, и даже с медиа работает, если его научить.
Чтобы получить от runserver файлы статики, нужно знать их адрес. Поведением сервера управляет настройка с названием STATIC_URL в файле settings.py . Если указано STATIC_URL = ‘/assets/’ , то браузер может получить файлы статики по адресу вида http://127.0.0.1:8000/assets/logo.png .
С путями к файлам статики всё несколько хитрее. В статье про веб-серверы упоминался STATIC_ROOT — это путь к каталогу, в котором веб-сервер ищет файлы статики. В файле settings.py есть настройка с таким названием STATIC_ROOT , и она влияет на работу веб-сервера в “боевом” режиме. А вот в отладочном режиме Django использует иной механизм. Так как файлов статики в больших проектах бывает много, то и хранить их удобнее не в одном каталоге STATIC_ROOT , а распределив по нескольким. Когда runserver получает запрос на очередной файл статики, то искать его он будет во всех каталогах, указанных в настройке STATICFILES_DIRS того же файла settings.py .
Для примера рассмотрим сайт Django с такими настройками в settings.py :
... STATIC_URL = '/assets/' STATICFILES_DIRS = [ '/home/site/static/', '/home/site/project/markup/', '/home/site/common/css/', ]
Если запустить отладочный веб-сервер runserver , то на запросы он будет реагировать так:
http://127.0.0.1:8000/assets/style.css
Адрес начинается с префикса, указанного в STATIC_URL — /assets/ , значит, это файл статики. Веб-сервер по очереди проверит каждый из каталогов в списке STATICFILES_DIRS , там будет искать файл style.css . Когда найдет — отправит файл браузеру.
http://127.0.0.1:8000/assets/imgs/logo.png
Снова адрес начинается с /assets/ , значит, веб-сервер будет искать файл статики imgs/logo.png в одном из каталогов STATICFILES_DIRS .
http://127.0.0.1:8000/static/photo.png
Префикс адреса /static/ не совпадает со значением STATIC_URL = ‘/assets/’ . Веб-сервер решит, что запрос относится к динамической части сайта, и попробует найти обработчик среди Python кода сайта. Скорее всего он ничего не найдет и вернет 404 Page not found.
Как подключить статику
Чтобы подключить файлы статики к Django вам достаточно выяснить две вещи: куда класть файлы и по какому адресу их получит браузер. Управляют этим две настройки STATIC_URL и STATICFILES_DIRS , обе живут в файле settings.py .
Отладочные print
Самый простой способ выяснить значение настроек — добавить отладочные print в конец файла settings.py :
print('STATIC_URL', STATIC_URL) print('STATICFILES_DIRS', STATICFILES_DIRS)
Теперь запустите в консоли любую команду с manage.py , например runserver , и увидите значение настроек:
$ python3 manage.py runserver . STATIC_URL /assets/ STATICFILES_DIRS ['/home/user/site/assets/']
Django Debug Toolbar
В больших проектах часто используют усложненные механизмы конфигурации и тогда простой способ с print может дать осечку. Но если на сайте установлено приложение Django Debug Toolbar, то у вас появляется второй вариант. Debug Toolbar это панель c отладочной информацией. Изначально панель свёрнута и отображается в виде небольшой сноски у правого края браузера. Развернув панель вы обнаружите несколько вкладок, вам понадобятся Settings и Static files :
Полезные ссылки
Если вы хотите ближе познакомиться с Django и разобраться во всех деталях, то начните погружение с этих статей:
- The staticfiles app
- Serving media files with runserver
- How to install Debug Toolbar
- Django Settings
Попробуйте бесплатные уроки по Python
Получите крутое код-ревью от практикующих программистов с разбором ошибок и рекомендациями, на что обратить внимание — бесплатно.
Переходите на страницу учебных модулей «Девмана» и выбирайте тему.