Когда Wagtail перестаёт быть роскошью на фоне привычного WordPress

MAATRIX

Кто-то в команде предложил Wagtail — и вы гуглите, что это вообще такое, потому что весь опыт с CMS до этого сводился к WordPress. Это нормальный вопрос: Wagtail — крепкая, взрослая CMS на Django, ей пользуются крупные издания и организации, у которых есть команда Python-разработчиков и нестандартные требования к контенту. Но это не значит, что она нужна вам. Ниже — разбор без маркетинга: чем Wagtail реально отличается от WordPress, где она выигрывает, а где превращается в лишнюю головную боль, и как понять, какой лагерь ваш.

Что такое Wagtail на самом деле

Wagtail — это CMS, написанная на Python поверх фреймворка Django, и это определяет всё остальное. Wagtail не устанавливается как готовое приложение с инсталлятором в браузере: это Django-проект, в который CMS подключается как набор приложений (apps). Модели данных, то есть типы страниц и их поля, описываются в коде — в файлах models.py — а не собираются кликами в панели администратора.

Из этого вытекают три следствия. Во-первых, у вас должна быть команда, которая пишет и деплоит Python-код: любое изменение структуры контента — новый тип страницы, новое поле — требует правки кода, миграции Django и релиза. Во-вторых, Wagtail не проект «поставил и работай»: сначала кто-то создаёт Django-проект, описывает модели, настраивает шаблоны на Django Template Language, и только потом редакторы получают удобную админку. В-третьих, база данных — PostgreSQL или MySQL — обязательна с первого дня, никакого SQLite в проде.

Взамен вы получаете то, чего WordPress не даёт без десятка плагинов: контент как код, который живёт в git, ревьюится в pull request'ах и деплоится вместе с остальным приложением. Гибкое поле StreamField позволяет собирать страницу из произвольных блоков — текст, галерея, встраиваемое видео, кастомный блок с калькулятором — и редактор комбинирует их в любом порядке, но набор допустимых блоков и их поведение определяет разработчик в коде, а не сторонний плагин непонятного происхождения.

WordPress: почему это всё ещё стандарт по умолчанию

WordPress не зря занимает такую долю рынка CMS: это система, которую можно поставить за десять минут и отдать редакции без единого разработчика в штате. Админка интуитивна, TinyMCE и блочный редактор Gutenberg знакомы почти всем, кто хоть раз работал с текстовым контентом в браузере. Хотите новый тип страницы — ставите плагин Advanced Custom Fields или Pods, настраиваете поля через интерфейс, без единой строчки кода.

Экосистема — главный козырь WordPress. Десятки тысяч плагинов и тем закрывают практически любую задачу: интернет-магазин через WooCommerce, форму бронирования, SEO-инструменты через Yoast, мультиязычность через WPML. Специалистов, которые умеют администрировать WordPress, найти на порядок проще и дешевле, чем Django-разработчиков — рынок труда здесь принципиально шире.

Оборотная сторона той же монеты — качество и безопасность плагинов сильно варьируются, а обновления WordPress-ядра, тем и десятков плагинов превращаются в постоянную рутину. Мы подробно разбирали типичный сценарий в статье про взлом сайта на WordPress — почти всегда точка входа это забытый плагин или тема, которые никто не обновлял месяцами.

Модель контента: код против кликов

Здесь пролегает главная граница между системами. В WordPress новый тип контента почти всегда означает: найти подходящий плагин, установить его, настроить поля через UI, надеяться, что плагин не бросят разработчики и он переживёт следующее крупное обновление ядра. Это быстро, но результат — надстройка над надстройкой: у вас в проекте живёт ACF, ещё пара плагинов для нужных типов записей, и логика контента размазана между базой, конфигурацией плагинов и темой.

В Wagtail тип страницы — это класс на Python, унаследованный от Page:

from wagtail.models import Page
from wagtail.fields import StreamField
from wagtail import blocks
from wagtail.admin.panels import FieldPanel

class ArticlePage(Page):
    intro = models.CharField(max_length=250)
    body = StreamField([
        ('heading', blocks.CharBlock(form_classname="title")),
        ('paragraph', blocks.RichTextBlock()),
        ('image', ImageChooserBlock()),
    ], use_json_field=True)

    content_panels = Page.content_panels + [
        FieldPanel('intro'),
        FieldPanel('body'),
    ]

Поле body здесь и есть StreamField — редактор в админке собирает страницу из блоков heading, paragraph, image в любом порядке и любом количестве, а список допустимых блоков и их валидацию контролирует разработчик. Хотите добавить блок с формой обратной связи или встроенным виджетом с курсом валют — пишете класс блока и делаете миграцию. Это дольше, чем поставить плагин, но результат — предсказуемая, тестируемая структура данных, которая не сломается от чужого обновления.

Для команды без Python-разработчиков этот путь мучителен: любая правка контентной модели становится тикетом к разработчикам вместо самостоятельного клика в админке. Для команды, у которой Django-разработчики уже есть на проекте (например, Wagtail подключают к существующему Django-приложению — личному кабинету, маркетплейсу, внутреннему порталу), это ровно тот инструмент, который органично встраивается в уже существующий стек, а не тянет за собой отдельный PHP-рантайм и MySQL только ради блога.

Безопасность и площадь атаки

Площадь атаки WordPress — это в первую очередь площадь атаки его плагинов и тем. Ядро WordPress обновляется быстро и обычно безопасно, но чем больше сторонних расширений в проекте, тем выше шанс, что одно из них окажется дырявым. Проверка, что стоит на сайте, и его актуальность — это скорее операционная рутина, чем разовая настройка; хороший ориентир — чек-лист безопасности нового сервера, который стоит прогонять регулярно, а не один раз при установке.

У Wagtail площадь атаки принципиально меньше — не потому что Python «безопаснее» PHP, а потому что там просто нет рынка сторонних плагинов сомнительного качества, устанавливаемых кликом. Зависимости — это Python-пакеты, которые явно прописаны в requirements.txt или pyproject.toml, проходят через тот же процесс ревью, что и остальной код проекта, и обновляются осознанно, а не автоматически из непроверенного репозитория. Это не значит, что Wagtail неуязвим — уязвимости в Django и его расширениях тоже случаются, но происходят реже и обычно закрываются раньше, чем эксплойт для очередного плагина ACF-конкурента набирает популярность в сканерах ботов.

Есть и обратная сторона: если в Wagtail-проекте что-то настроено криво — открыт Django admin без ограничения по IP, DEBUG=True утёк в продакшен, секретный ключ закоммичен в репозиторий — последствия будут не менее тяжёлыми, чем взлом WordPress через плагин. Безопасность здесь смещается с «обновляй плагины» на «настрой Django правильно с первого раза»: вынеси секреты в переменные окружения, ограничь доступ к /admin/ через VPN или список IP, следи за обновлениями самого Django, у которого тоже бывают security-релизы вне графика.

Кто должен обслуживать систему: разработчик или редактор

Ключевой практический вопрос — не «что мощнее», а «кто будет с этим жить дальше». WordPress проектировался так, чтобы владелец малого бизнеса или маркетолог мог самостоятельно вести сайт: писать статьи, менять баннеры, редактировать меню — без единого обращения к разработчику. Это его суперсила, и для 90% сайтов — блогов, лендингов, сайтов-визиток, небольших интернет-магазинов — это ровно то, что нужно.

Wagtail рассчитан на другую конфигурацию команды: редакторы работают в удобной, хорошо продуманной админке (она у Wagtail действительно приятная — с превью, версионированием черновиков, workflow согласования публикаций), но структуру и логику проекта поддерживают разработчики. Если у вас нет штатного или подрядного Python/Django-разработчика — Wagtail станет проектом, который через полгода некому будет обновлять, а любая мелкая правка контентной модели встанет в очередь на месяцы.

Обратная ситуация тоже реальна: если у вас уже есть Django-приложение — например, платформа с личными кабинетами, каталогом, биллингом на Django — и к нему нужно приделать блог, лендинги или раздел новостей, городить рядом отдельный WordPress на PHP с собственной базой, собственным хостингом PHP-FPM и отдельной системой авторизации — избыточно и неудобно. Wagtail в этом случае подключается как ещё одно Django-приложение, использует ту же базу, ту же систему пользователей, тот же деплой — и экономит именно на интеграции, а не на самой CMS.

Инфраструктура и совокупная стоимость владения

С точки зрения сервера оба стека скромны по требованиям для старта, но живут по-разному. Классический стек WordPress — это PHP-FPM, Nginx или Apache и MySQL/MariaDB; поднимается по проверенным гайдам и хорошо документирован, разворачивается за один проход от чистого сервера до рабочего сайта.

Wagtail-проект — это Python-приложение, которое нужно завести под WSGI-сервером (обычно Gunicorn) за реверс-прокси Nginx, плюс PostgreSQL как основная база — Wagtail официально ориентирован на неё, хотя формально поддерживает и MySQL. Разворачивание PostgreSQL под проект хорошо описано в статье про установку и настройку PostgreSQL на VPS. Если сомневаетесь, какую базу вообще брать под новый проект — сравнение PostgreSQL и MySQL поможет определиться независимо от выбора CMS.

Совокупная стоимость владения — это не только хостинг, который в обоих случаях укладывается в бюджет обычного VPS. Основная статья расходов — люди. WordPress-специалист на рынке труда стоит дешевле и найти его проще; для несложного сайта его услуг может не понадобиться вообще, если контент ведут сами сотрудники. Python/Django-разработчик стоит дороже, и без него Wagtail-проект просто не живёт — любое развитие требует релиза кода. Если считать честно, точку, где Wagtail становится выгоднее по TCO, определяет не объём контента, а наличие у вас разработчиков, которых всё равно нужно содержать под остальную часть продукта — тогда CMS достаётся «бесплатным довеском» к их работе, а не отдельной строкой расходов.

Как выбрать: чек-лист под вашу команду

Сведём разбор к практическим критериям, по которым стоит принимать решение:

Если в большинстве строк выигрывает правая колонка — берите WordPress без сомнений, это не «второй сорт», а инструмент, который на 90% задач объективно эффективнее по деньгам и времени. Если у вас уже есть Django-стек, нестандартный контент и команда, которая может это поддерживать, — Wagtail окупится тем, что контент станет частью нормального процесса разработки, а не отдельным зоопарком плагинов.

Частые вопросы