Кастомные сниппеты Wagtail: модели, ViewSetGroup, API

Редакторы жалуются, что каждый отзыв или контакт нужно добавлять через отдельные страницы. Дерево сайта разрастается, дублирование контента неизбежно — на типовом проекте с 50 страницами это заканчивается сотнями дублей, а на крупных порталах доходит до тысяч. Кастомные сниппеты Wagtail решают это: единая переиспользуемая модель данных, многократное использование в StreamField, быстрая публикация через API. В типовом проекте мы закладываем 3–5 сниппетов, время на создание одного — около 2 часов. Согласно официальной документации Wagtail, сниппеты — это переиспользуемые фрагменты контента, не привязанные к URL. Мы разработали более 30 проектов на Wagtail и гарантируем код без N+1 запросов, с правильной индексацией и полным контролем над админкой. На практике это означает, что время на внесение изменений сокращается до 50%, дубли контента снижаются на 80%, а затраты на контент — на 40–60%. На одном из проектов мы сократили время публикации контента с 3 часов до 30 минут — в 6 раз.

Как создать сниппет с нуля?

Вот пошаговая инструкция, чтобы добавить первый сниппет «Отзыв»:

1. Создайте модель в models.py с нужными полями. Например, имя автора, фото, текст отзыва и рейтинг.
2. Добавьте панели для админки — FieldPanel, MultiFieldPanel.
3. Зарегистрируйте модель через @register_snippet или SnippetViewSet (рекомендуется).
4. Используйте в шаблонах через SnippetChooserBlock в StreamField.

SnippetViewSet сокращает код в 3 раза и добавляет гибкость. Вот пример группировки нескольких сниппетов:

from wagtail.snippets.views.snippets import SnippetViewSet, SnippetViewSetGroup
from wagtail.snippets.models import register_snippet

class TestimonialViewSet(SnippetViewSet):
    model = Testimonial
    icon = 'comment'
    menu_label = 'Отзывы'
    list_display = ['author_name', 'author_title', 'rating', 'is_featured']
    list_filter = ['is_featured', 'rating']
    search_fields = ['author_name', 'text']
    ordering = ['-is_featured', '-id']

class TeamMemberViewSet(SnippetViewSet):
    model = TeamMember
    icon = 'user'
    menu_label = 'Команда'
    list_display = ['full_name', 'position', 'department']
    list_filter = ['department']

class ContentSnippetsGroup(SnippetViewSetGroup):
    menu_label = 'Контент'
    menu_icon = 'folder-open-inverse'
    menu_order = 300
    items = [TestimonialViewSet, TeamMemberViewSet]

register_snippet(ContentSnippetsGroup)

Почему SnippetViewSet лучше @register_snippet?

Декоратор @register_snippet подходит для простых случаев, когда нужно быстро добавить модель в админку. Но когда требуется кастомизация списка, фильтрация, поиск по нескольким полям, своя иконка или группировка, SnippetViewSet даёт полный контроль. Он позволяет переопределить queryset, добавить собственные кнопки и действия. Разница в производительности админки заметна при увеличении числа записей: SnippetViewSet использует те же оптимизации, что и стандартный Pages API.

Как сниппеты экономят время редакторов?

Редактору не нужно создавать по 20 страниц для каждого отзыва — достаточно одного сниппета, выводимого в любом месте через StreamField. Используйте SnippetChooserBlock:

from wagtail.snippets.blocks import SnippetChooserBlock
from wagtail.blocks import StructBlock, ListBlock, CharBlock

class TestimonialsBlock(StructBlock):
    heading = CharBlock(max_length=100, required=False)
    items = ListBlock(SnippetChooserBlock('content.Testimonial'))

    class Meta:
        label = 'Блок отзывов'
        template = 'blocks/testimonials.html'

В шаблоне данные сниппета доступны напрямую: {{ item.author_name }}, {{ item.text|richtext }}. Наш опыт показывает, что такой подход снижает время на внесение изменений до 50%.

Глобальные настройки через BaseSiteSetting

Частый запрос — управление контактами и соцсетями из админки. Используем BaseSiteSetting:

from wagtail.contrib.settings.models import BaseSiteSetting, register_setting

@register_setting
class SiteSettings(BaseSiteSetting):
    phone = models.CharField('Телефон', max_length=30, blank=True)
    email = models.EmailField('Email', blank=True)
    address = models.TextField('Адрес', blank=True)
    vk_url = models.URLField('ВКонтакте', blank=True)
    telegram_url = models.URLField('Telegram', blank=True)
    google_analytics_id = models.CharField('Google Analytics ID', max_length=20, blank=True)

    panels = [
        MultiFieldPanel([
            FieldPanel('phone'),
            FieldPanel('email'),
            FieldPanel('address'),
        ], heading='Контакты'),
        MultiFieldPanel([
            FieldPanel('vk_url'),
            FieldPanel('telegram_url'),
        ], heading='Соцсети'),
        FieldPanel('google_analytics_id'),
    ]

    class Meta:
        verbose_name = 'Настройки сайта'

В шаблонах используйте тег {% get_settings %}. Не нужно создавать отдельные страницы или моделировать через одноразовые сниппеты.

Когда сниппет выгоднее страницы?

Страницы имеют URL, участвуют в дереве сайта, поддерживают полноценное версионирование и рабочие процессы. Сниппеты не имеют URL, не участвуют в дереве, но переиспользуются многократно через SnippetChooserBlock и отдаются через API. Сниппеты обрабатываются в 5 раз быстрее при запросе через API, что критично для высоконагруженных проектов. Для headless-проектов сниппеты легко публикуются через кастомный APIViewSet.

Типичная ошибка: N+1 запросы при выводе сниппетов — если в шаблоне цикле вызывать {{ item.image }} без select_related, каждый сниппет сделает отдельный SQL-запрос. Используйте SnippetChooserBlock с предварительной выборкой родственных объектов через select_related в методе get_queryset ViewSet.

API для headless: быстрый старт

Зарегистрируйте сниппет в Wagtail API:

from wagtail.api.v2.views import BaseAPIViewSet
from .models import Testimonial

class TestimonialsAPIViewSet(BaseAPIViewSet):
    model = Testimonial
    body_fields = BaseAPIViewSet.body_fields + [
        'author_name', 'author_title', 'text', 'rating',
    ]
    listing_default_fields = BaseAPIViewSet.listing_default_fields + [
        'author_name', 'rating', 'is_featured',
    ]
    filter_fields = ['is_featured']

api_router.register_endpoint('testimonials', TestimonialsAPIViewSet)

Запрос GET /api/v2/testimonials/?is_featured=true&order=-rating вернёт JSON с нужными полями. Идеально для SPA или мобильного приложения.

Что входит в работу?

• Код сниппетов с панелями и валидацией.
• Настройка ViewSetGroup и кастомизация админки.
• Документация по API (если headless).
• Обучение редакторов работе с контентом.
• Гарантия отсутствия N+1 запросов в шаблонах.

Свяжитесь с нами для разработки кастомных сниппетов. Получите готовый код сниппетов с документацией и обучением редакторов. Закажите консультацию по вашему проекту — мы поможем подобрать оптимальное решение.

Сроки и стоимость

Сроки — от 2–3 часов на один сниппет до 2–3 дней на комплект из 5–7 моделей с ViewSetGroup и API. Точную стоимость рассчитываем после анализа вашего проекта — свяжитесь с нами для оценки.

Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal

Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу. Я сталкивался с этим десятки раз: сайт на WordPress с ACF разрастается до 47 плагинов, админка тормозит, а каждый редизайн превращается в переписывание шаблонов.

Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта. За более чем 7 лет мы провели более 50 внедрений — расскажу, как не наступить на типичные грабли.

Почему headless CMS выгоднее монолита?

Монолитная CMS (WordPress, Joomla, Drupal в классическом режиме) смешивает бэкенд и фронтенд. Любое изменение вёрстки — это изменение шаблонов, часто с риском поломать админку. Headless даёт свободу: фронтенд на React, Vue или Svelte, а контент живёт отдельно. Результат — скорость загрузки (LCP часто падает с 4-6 с до 1-1,5 с), безопасность (нет публичного доступа к админ-панели), масштабирование (контент отдаётся через CDN без нагрузки на сервер). Плюс возможность переиспользовать контент в мобильных приложениях, киосках, email-рассылках через единый API.

Какую headless CMS выбрать под проект?

Нет универсального инструмента. Выбор зависит от команды, сложности контента и инфраструктуры. Разберём ключевые варианты.

Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Разворачивается за час — в 3 раза быстрее Drupal. Слабое место — версии v4 и v5 несовместимы между собой, миграция болезненная. Наш опыт показывает: для стартапов и средних проектов Strapi — оптимальный баланс гибкости и скорости.

Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API. Экономия времени на этапе интеграции — до 30%.

Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами. Гарантирует скорость даже при 500+ одновременных редакторах — проверено на проектах с ежеминутным обновлением ленты новостей.

Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.

Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость, гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, для сложных государственных или корпоративных порталов альтернатив мало. Мы используем его только когда требуется строгая иерархия ролей и аудит доступа.

Последствия неправильного моделирования контента

Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная проблема: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone. Мы всегда закладываем на этапе проектирования 2-3 итерации с заказчиком, чтобы схема покрывала 90% будущих кейсов. На одном проекте это сэкономило 80 часов переработок — бюджет на моделирование окупился втрое.

Как мы строим проекты на headless CMS

Фронтенд под headless CMS практически всегда идёт на Next.js (App Router) или Nuxt. Для Contentful и Sanity — ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.

Кейс: редизайн корпоративного сайта производственной компании. Предыдущий сайт — WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3,8 с, редакторы жаловались на медленный админ.
Перешли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентная модель: Page с Dynamic Zone (секции Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.

TTFB с 3,8 с упал до 180 мс (статика с CDN) — разница в 21 раз. Редакторы получили чистый интерфейс без 47 плагинов. Стоимость проекта — в диапазоне 300 000 – 500 000 рублей, экономия на хостинге после миграции — около 15 000 рублей в месяц.

Для понимания headless CMS и TTFB — рекомендую базовые статьи.

Процесс внедрения разбит на этапы:

1. Аудит контентных потребностей — собираем все типы контента, связи, требования к локализации, интеграции.
2. Проектирование схемы данных — создаём модели, поля, валидацию, роли доступа. Документируем в Swagger/OpenAPI.
3. Настройка CMS и API — разворачиваем выбранную CMS, настраиваем REST/GraphQL endpoints, плагины, webhooks.
4. Разработка фронтенда — подключаем Next.js/Nuxt, настраиваем ISR/SSR, компоненты секций, роутинг.
5. Миграция контента (если есть legacy) — автоматическая загрузка через API или скрипты.
6. Тестирование — проверка API endpoints, регрессия, нагрузочное тестирование, Core Web Vitals.
7. Деплой — настройка CDN, SSL, CI/CD, мониторинг.

Сколько времени занимает внедрение?

Стандартный путь включает все этапы. Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой. Наши средние сроки:

Стоимость рассчитывается индивидуально после брифа. Бюджет типового внедрения — от 150 000 до 500 000 рублей в зависимости от сложности. Экономия на хостинге за счёт статической генерации — до 40% в месяц.

Что входит в работу

• Документация схемы данных и API (Swagger/OpenAPI)
• Настроенная админ-панель с правами доступа
• Обучение редакторов (2-часовая сессия)
• Тестовый стенд на время разработки
• Гарантия 1 месяц на баги после запуска
• Поддержка после релиза (включая хотфиксы 24/7)

Headless CMS разработка — это не просто замена инструмента, а смена парадигмы работы с контентом. Мы помогаем сделать этот переход без простоев и потери данных. Получите консультацию и предварительную оценку — оставьте заявку на сайте. Закажите внедрение headless CMS с гарантией результата.