add: Контекстный процессор, для передачи состояния IS_DEBUG и ALLOW_TRACKING в шаблоны.

This commit is contained in:
2026-08-14 14:28:06 +03:00
parent 7ec030e75c
commit d75606c952
2 changed files with 59 additions and 0 deletions
+1
View File
@@ -95,6 +95,7 @@ TEMPLATES = [
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
'hypn0_site.context_processors.site_context',
],
},
},
+58
View File
@@ -0,0 +1,58 @@
from django.conf import settings
from django.http import HttpRequest
# Имя куки, которая ставится клиенту, когда он СОГЛАСИЛСЯ на отслеживание
# (Google Tag Manager, Яндекс.Метрика и т.п.). Если кука присутствует —
# предупреждение о трекинге больше не показываем.
ALLOW_TRACKING_COOKIE_NAME = "allow_tracking"
def site_context(request: HttpRequest) -> dict:
"""
Общий (универсальный) контекст-процессор Django для всего проекта.
ЗАЧЕМ ЭТО НУЖНО:
Автоматически добавляет во ВСЕ шаблоны проекта переменные, которые
нужны почти на каждой странице, без необходимости передавать их
вручную в контексте каждой вьюхи. Контекст-процессор необходимо
зарегистрировать в settings.py: TEMPLATES['OPTIONS']['context_processors']
ПОЧЕМУ ОДИН УНИВЕРСАЛЬНЫЙ ПРОЦЕССОР, А НЕ НЕСКОЛЬКО РАЗНЫХ:
И DEBUG-флаг, и флаг согласия на трекинг — это одинаковые по сути
"сквозные" данные: маленькие, не завязанные на конкретную вьюху,
нужные почти во всех шаблонах (в _base.html). Заводить под каждую
такую мелочь отдельный контекст-процессор — это лишний файл и лишняя
строка регистрации в settings.py на ровном месте. Если в будущем
появится много разнородных "сквозных" переменных — тогда, возможно,
стоит разнести их по смыслу (например, отдельно cookies-consent,
отдельно debug/env), но пока их всего две — держим вместе.
ПОЧЕМУ НЕ штатный django.template.context_processors.debug (для IS_DEBUG):
Штатный context-processor отдаёт переменную `debug` только если
ОДНОВРЕМЕННО: settings.DEBUG == True И IP клиента входит в
settings.INTERNAL_IPS (сверяется по request.META['REMOTE_ADDR']).
В проекте с Docker/reverse-proxy — REMOTE_ADDR может быть не 127.0.0.1,
а IP шлюза docker-сети, и потому штатный контекстный-процессор ненадёжен.
ПРО ALLOW_TRACKING:
Читаем куку request.COOKIES.get(ALLOW_TRACKING_COOKIE_NAME) — её
ставит клиентский JS (или сервер) ПОСЛЕ того, как пользователь
согласился с предупреждением об отслеживании (Google Tag Manager,
Яндекс.Метрика и т.п.). Если кука присутствует (независимо от её
значения — само наличие куки уже означает согласие) — предупреждение
в шаблоне больше не показываем, а также можно подключать сами
счётчики трекинга ({% if ALLOW_TRACKING %}...{% endif %}).
:return
dict: словарь с ключами:
IS_DEBUG (bool) — режим отладки Django (settings.DEBUG);
ALLOW_TRACKING (bool) — согласился ли клиент на отслеживание
(определяется по наличию куки "allow_tracking").
Обе переменные доступны во всех шаблонах:
{% if IS_DEBUG %}...{% endif %}
{% if ALLOW_TRACKING %}...{% endif %}
"""
return {
"IS_DEBUG": settings.DEBUG,
"ALLOW_TRACKING": ALLOW_TRACKING_COOKIE_NAME in request.COOKIES,
}