Wagtail как Django admin на стероидах

Хороший разбор для Django-разработчиков: Wagtail можно использовать не только как CMS, но и как более удобную админку для обычных Django-моделей.

Смысл простой: Django admin быстро даёт UI вокруг моделей, но кастомизация часто превращается в боль. Wagtail даёт более современный интерфейс, нормальную работу с полями, группировку через panels, роли, permissions, rich text, media library, versioning и редакторские workflow.

При этом не нужно переписывать проект под CMS-логику. Wagtail ставится как обычный Django-пакет, добавляется в INSTALLED_APPS, подключается в urls.py, а бизнес-логика, views, forms и templates остаются обычными Django.

Самый практичный случай использования : взять существующий admin.py, перенести модели в Wagtail snippets и постепенно заменить старую админку там, где нужен интерфейс, который не стыдно показать клиенту.

Для внутренних тулзов, CRM, backoffice и контентных разделов это может быть намного приятнее, чем бесконечно допиливать стандартный Django admin.

https://timonweb.com/wagtail/wagtail-as-django-admin-on-steroids/

⚡️ django-orjson ускоряет работу Django с JSON

Adam Johnson выпустил библиотеку django-orjson с готовыми заменами стандартных JSON-компонентов Django и Django REST Framework.

В основе лежит написанный на Rust orjson:

- сериализация до 10 раз быстрее;
- десериализация примерно в 2 раза быстрее.

Поддерживаются:

- JsonResponse и тестовый клиент;
- json_script;
- сериализаторы, сессии и signing;
- компоненты Django REST Framework.

Пакет протестирован на поддерживаемых версиях Python и Django, заявлено 100% покрытие ветвей.

Также обсуждается подключаемый JSON-бэкенд для самого Django. Тогда стандартный json можно будет заменить на orjson централизованно, без изменения импортов по всему проекту.

https://adamj.eu/tech/2026/07/15/introducing-django-orjson/

🚀 Django 6.1 вышел: меньше магии, больше контроля

Новая версия Django приносит улучшения для production-приложений и работы с базой данных.

Главное новшество — новый подход к загрузке данных моделей.

Теперь можно контролировать, когда Django делает дополнительные запросы:

from django.db import models

books = Book.objects.fetch_mode(
    models.FETCH_PEERS
)

Это помогает бороться с проблемой N+1 запросов и лучше контролировать нагрузку на БД.

Новые режимы:

- FETCH_ONE — загружать данные только для текущего объекта;
- FETCH_PEERS — догружать данные сразу для группы объектов;
- RAISE — запрещать неожиданные запросы и ловить проблемы заранее.

Также в Django 6.1:

- поддержка Python 3.12, 3.13 и 3.14;
- PostgreSQL 15+;
- MySQL 8.4+;
- MariaDB 10.11+;
- улучшения cache и внутренних механизмов.

Главная идея релиза:

Django всё меньше скрывает стоимость операций и даёт разработчикам больше контроля над тем, что происходит под капотом.

Подробнее:
https://www.djangoproject.com/weblog/2026/aug/05/django-61-released/

🐍 Django-разработчикам: `DEBUG=True` в проде опаснее, чем кажется.

Это не просто красивые страницы ошибок. При включённом DEBUG приложение может раскрывать stack trace, настройки, пути файлов, middleware, URL-паттерны и другие детали окружения.

Главная рекомендация - fail closed:

DEBUG = False

То есть по умолчанию DEBUG всегда выключен, а включается только локально.

Даже staging, QA и preview-среды, доступные из интернета, лучше запускать с DEBUG=False.

Отдельная ловушка - переменные окружения:

DEBUG = os.environ.get("DEBUG", "False") != "False"

Здесь DEBUG=false или DEBUG=0 могут неожиданно превратиться в True.

Лучше явно парсить boolean или использовать django-environ.

Мелкая настройка, которая однажды может спасти production от очень неприятной утечки.

https://lincolnloop.com/blog/setting-djangos-debug-safely/

#Python #Django #Backend #Security #DevOps