Обычно нет. Администратор может использовать уже настроенные блоки, а новый тип блока добавляет разработчик. Это связано с тем, что блок должен работать не только в админке, но и на публичной странице сайта.
Если в админке Wagtail нет нужного блока, это не всегда ошибка. Чаще всего набор блоков зависит от типа страницы, структуры конкретного сайта и решений, которые были заложены при проектировании и разработке.
Администратор или редактор может проверить, есть ли похожий блок, доступен ли нужный блок на других страницах и можно ли решить задачу существующими средствами. Но если нужен новый формат контента — например, карточки преимуществ, FAQ, CTA-блок, галерея или блок этапов работы, — обычно это задача для разработчика.

Wagtail не работает как конструктор, где можно произвольно собрать любую секцию из готового набора. Его сила в другом: блоки проектируются под конкретный сайт, чтобы редактор мог удобно заполнять контент, а страница сохраняла аккуратный внешний вид и правильную структуру.
Если нужный формат повторяется регулярно, лучше не собирать его вручную из текста, картинок и пробелов. Правильнее описать задачу и добавить отдельный управляемый блок.
В Wagtail набор блоков обычно не универсальный для всего сайта. Он зависит от того, как разработан конкретный проект.
На одном сайте редактор может видеть текстовые блоки, изображения, галереи, документы и FAQ. На другом — карточки услуг, блоки преимуществ, отзывы, тарифы и подборки материалов. На третьем сайте набор будет совсем другим, потому что у проекта другие задачи.
Это нормальная логика Wagtail. CMS не навязывает всем одинаковую админку, а позволяет собрать её под структуру сайта, редакционные процессы и бизнес-задачи.
Самая частая причина простая: нужный блок не был заложен при разработке.
Например, на этапе запуска сайта были нужны только обычные текстовые блоки, изображения и документы. Через несколько месяцев команда решила, что на страницах услуг хорошо бы добавить блок с преимуществами, иконками и короткими описаниями. Если такого блока раньше не было в задаче, он сам в админке не появится.
Это не поломка. Это значит, что сайт вырос до новой потребности.
Хороший Wagtail-проект может развиваться постепенно: сначала запускается базовая структура, затем добавляются новые блоки, типы страниц, формы, интеграции и редакционные возможности. Главное — не путать развитие сайта с ручными обходными решениями.
В Wagtail разные страницы могут иметь разные наборы блоков.
Например, у страницы услуги может быть один набор: текст, преимущества, этапы работы, форма заявки. У статьи блога — другой: текст, изображение, цитата, таблица, FAQ. У главной страницы — третий: промо-блок, подборки, баннеры, карточки направлений.
Это делается не для того, чтобы усложнить жизнь редактору. Наоборот, такая логика помогает не смешивать разные задачи.
Если дать всем страницам все возможные блоки, админка быстро превратится в склад без подписей: вроде всё есть, но найти нужное невозможно, а использовать правильно — ещё сложнее.
Если блок есть на одной странице, это не означает, что он автоматически должен быть доступен на любой другой. Подробнее эту тему стоит раскрывать отдельно — в статье о том, почему разные страницы Wagtail имеют разные наборы блоков.
Иногда блок отсутствует не потому, что о нём забыли, а потому что его сознательно ограничили.
Например, крупный промо-блок может быть уместен на главной странице, но странно смотреться внутри обычной новости. Блок тарифов может быть нужен на странице услуги, но не нужен в разделе «О компании». Сложная галерея может быть полезна в портфолио, но лишняя в короткой информационной статье.
Такие ограничения защищают сайт от хаоса.
Редактору кажется: «Дайте мне все блоки, я сам разберусь». На практике это часто заканчивается страницами, которые выглядят по-разному, нарушают дизайн и усложняют поддержку. Wagtail хорош именно тем, что позволяет сделать редактору не бесконечный набор кнопок, а понятный рабочий инструмент.
Иногда вопрос связан с правами пользователя или настройками раздела. Один пользователь может редактировать только новости, другой — страницы услуг, третий — документы или раздел базы знаний.
Обычно права доступа больше связаны с разделами, страницами и действиями, чем с отдельными блоками. Поэтому не стоит сразу считать, что проблема именно в правах. Чаще причина в типе страницы и наборе блоков, который заложен в проекте.
Если вы уверены, что нужный блок должен быть доступен, но вы его не видите, стоит уточнить у администратора проекта или технического специалиста.
Главная задача проверки — понять, с какой ситуацией вы столкнулись.
Блока может не быть вообще. Блок может называться иначе. Блок может быть доступен только на другом типе страницы. Или задача может решаться уже существующим блоком, просто не самым очевидным.
Паниковать не нужно. В админке Wagtail отсутствие блока чаще означает не «всё сломалось», а «для этой задачи пока не предусмотрен отдельный инструмент».

Не каждая задача требует разработки нового блока.
Если нужно добавить обычный текст, короткое пояснение, изображение, ссылку, небольшой список или документ, скорее всего, достаточно уже существующих блоков.
Например, для простого пояснения под заголовком не нужен отдельный сложный блок. Для ссылки на PDF можно использовать текстовый блок или блок документа, если он предусмотрен в проекте. Для небольшой иллюстрации подойдёт блок изображения.
Но здесь есть важная граница.
Если вы начинаете использовать пустые строки для отступов, таблицы для имитации карточек, скриншоты вместо нормального текста или вручную копируете сложную конструкцию с другой страницы, лучше остановиться. Это уже не редактирование контента, а попытка заменить разработку ручной сборкой.
Такой способ может выглядеть приемлемо в редакторе, но плохо работать на сайте. Особенно на мобильных устройствах.
В Wagtail лучше использовать блоки по назначению. Текстовый блок — для текста. Изображение — для изображения. Документ — для документа. А если нужен сложный повторяемый формат, его стоит оформить как отдельный управляемый блок.
Новый блок нужен не всегда. Но есть ситуации, когда без него сайт начинает развиваться криво.
| Ситуация | Можно ли решить без разработки | Что лучше сделать |
|---|---|---|
| Нужно добавить обычный текст | Да | Использовать текстовый блок |
| Нужно разово добавить изображение или ссылку | Обычно да | Проверить существующие блоки |
| Один и тот же формат нужен на многих страницах | Нежелательно вручную | Сделать отдельный блок |
| Нужны карточки с заголовками, текстами, иконками и ссылками | Обычно нет | Поставить задачу на новый блок |
| Блок влияет на заявки, переходы или продажи | Лучше не собирать вручную | Спроектировать и разработать аккуратно |
| Разные редакторы собирают один формат по-разному | Нет, будет хаос | Стандартизировать блок |
| Для нового раздела нужны повторяемые блоки: карточки, FAQ, CTA, документы | Частично | Обсудить доработку структуры и блоков |
Новый блок стоит делать, если формат будет использоваться регулярно. Например, на сайте появляются страницы услуг, и на каждой нужна одинаковая структура: преимущества, этапы работы, документы, FAQ и форма заявки.
Также новый блок нужен, если внутри элемента есть несколько управляемых частей: иконка, заголовок, текст, ссылка, кнопка, изображение, порядок карточек.
Примеры блоков, которые часто имеет смысл добавлять в Wagtail-проект:
Если такой блок нужен один раз, можно подумать. Если он нужен на десяти страницах, думать уже поздно — пора проектировать нормально.

Главная ошибка редактора — попытаться собрать отсутствующий блок из того, что есть под рукой.
Например, нужны карточки преимуществ. В админке есть только текстовый блок и изображение. Редактор добавляет заголовки, вставляет картинки, делает списки, расставляет пустые строки, где-то добавляет жирный текст. На одной странице это ещё выглядит терпимо. На второй — немного иначе. На третьей приходит другой редактор, копирует по-своему, и сайт постепенно начинает жить по законам устного народного творчества.
Проблема не в том, что редактор плохо старается. Проблема в том, что инструмент не предназначен для такой задачи.
Ручная сборка сложных блоков приводит к нескольким проблемам.
Страница может плохо выглядеть на мобильных устройствах. То, что кажется ровным на большом экране, легко разваливается на телефоне.
Нарушается единый стиль сайта. Один и тот же блок на разных страницах начинает выглядеть по-разному.
Контент становится сложнее поддерживать. Следующий редактор не понимает, что здесь можно менять, а что лучше не трогать.
Появляются ошибки в ссылках, изображениях, отступах и заголовках.
Сайт теряет аккуратность. Это заметно не сразу, но через несколько месяцев такие ручные решения превращаются в редакционный чердак: всё вроде нужное, но лучше не открывать без фонарика.
Если один и тот же блок приходится каждый раз собирать руками, это уже не редакторская задача, а кандидат на доработку сайта.
Администратору не нужно знать, как новый блок будет устроен внутри Wagtail. Не нужно писать техническое задание языком разработчика, упоминать код, модели или шаблоны.
Нужно описать задачу с точки зрения сайта и редактора.
В хорошем описании нового блока стоит указать:
К описанию полезно приложить ссылку на страницу, где нужен блок, скриншот текущей ситуации или пример похожего решения. Это помогает быстрее понять задачу и не играть в редакторско-разработческую угадайку.
Главное — описать не техническую реализацию, а смысл.
Плохая постановка задачи:
«Добавьте красивый блок для преимуществ».
Разработчик после такой фразы понимает примерно столько же, сколько врач после сообщения «что-то болит». Вроде направление ясно, но лечить пока рано.
Хорошая постановка задачи:
«Нужен блок «Преимущества услуги» для страниц услуг. В блоке должны быть общий заголовок, короткое описание и от 3 до 6 карточек. В каждой карточке: иконка, заголовок и текст до 150 символов. Редактор должен уметь менять порядок карточек и добавлять новые без помощи разработчика».
Такое описание уже можно обсуждать, оценивать и превращать в задачу на разработку.
Представим обычную ситуацию.
Редактор готовит страницу новой услуги. На странице нужно показать четыре преимущества: быстрая обработка заявки, персональный менеджер, прозрачные этапы работы и поддержка после запуска.
В админке есть текстовый блок, изображение и кнопка. Отдельного блока «Преимущества» нет.
Можно пойти плохим путём: вручную добавить заголовки, вставить иконки как изображения, написать тексты списком, выровнять пустыми строками и надеяться, что всё будет выглядеть прилично.
Проблема в том, что такой блок будет трудно повторить. На следующей странице редактор добавит пять преимуществ, другой поставит изображения другого размера, третий забудет про заголовок. В итоге один и тот же смысловой элемент будет выглядеть по-разному.
Хороший путь — описать новый блок.
Например:
«Нужен блок «Преимущества услуги» для страниц услуг. В блоке должны быть общий заголовок, короткое описание и от 3 до 6 карточек. В каждой карточке: иконка, заголовок и текст до 150 символов. Блок должен быть доступен на страницах услуг. Редактор должен уметь менять порядок карточек и добавлять новые без помощи разработчика».
После разработки редактору не нужно будет каждый раз изобретать оформление. Он просто заполнит поля: заголовок, описание, карточки, иконки и тексты.
Такой блок сохраняет единый дизайн, ускоряет работу, снижает риск ошибок и делает сайт понятнее для команды.

Новый блок — это не просто ещё одна кнопка в админке. Это управляемый элемент сайта, который должен быть удобен редактору и корректно отображаться для посетителя.
Обычно разработчик:
Иногда задача действительно небольшая. Иногда новый блок требует дизайна, вёрстки, согласования поведения на разных экранах и проверки на уже существующих страницах.
После добавления блока его стоит проверить на черновой или тестовой странице: посмотреть, удобно ли заполняются поля, корректно ли всё отображается на компьютере и мобильном экране, не ломается ли страница при разном количестве элементов.
Не стоит воспринимать добавление блока как мгновенное «включение настройки». В Wagtail блок — часть системы сайта. Если сделать его аккуратно, он потом долго помогает редакторам. Если сделать наспех, он быстро станет ещё одной маленькой проблемой в админке.

Если нужного блока нет, это не всегда ошибка. Возможно, блок просто не предусмотрен для этого типа страницы или для проекта в целом.
Сначала стоит проверить доступные блоки, тип страницы и похожие страницы сайта.
Это самая частая ошибка. Редактор пытается заменить отсутствующий блок текстом, картинками, таблицами и пустыми строками.
В результате страница может плохо выглядеть на мобильных устройствах, а одинаковые элементы на сайте начинают оформляться по-разному.
Текстовый блок подходит для текста: абзацев, заголовков, списков, простых ссылок.
Но он не всегда подходит для карточек, сеток, CTA, галерей, FAQ, тарифов и других сложных элементов. Если текстовый блок превращается в ручной конструктор, значит, задачу стоит пересмотреть.
Фраза понятная, но бесполезная для разработки. Разработчику нужно понимать, где блок будет использоваться, какие поля нужны, кто будет его заполнять и как он должен выглядеть на странице.
Чем точнее описана задача, тем меньше недопонимания.
Не каждый разовый элемент нужно превращать в отдельный блок. Если задача простая, не повторяется и спокойно решается существующими средствами, лучше не усложнять админку.
Хорошая админка — это не та, где есть всё на свете. Хорошая админка — та, где есть нужное и нет лишнего.
Иногда нужный блок уже есть, но доступен только на другом типе страницы.
Перед постановкой задачи стоит проверить похожие страницы. Возможно, решение уже реализовано, но не подключено там, где вы сейчас работаете.
Администратор может многое сделать сам: выбрать доступный блок, заполнить поля, добавить текст, изображение, ссылку или документ, проверить страницу перед публикацией, найти похожий блок и подготовить описание задачи.
Но есть задачи, которые относятся к разработке.
К разработчику стоит обращаться, если нужен новый тип блока, нужно изменить внешний вид существующего блока, добавить новые поля, сделать карточки, FAQ, галерею, CTA или другой управляемый формат.
Также разработчик нужен, если блок должен быть доступен на разных типах страниц, если требуется автоматическая подборка материалов, если блок связан с формой, CRM, каталогом или другой системой.
Ещё один важный сигнал — редакторы регулярно обходят ограничения вручную. Если команда постоянно собирает один и тот же формат из случайных элементов, значит, сайту не хватает нормального инструмента.
Иногда вопрос шире, чем один новый блок. Если для нового раздела нужна особая структура, свои поля, свой набор блоков и отдельная логика вывода, возможно, речь уже о новом типе страницы. Это лучше обсуждать с разработчиком или командой сопровождения заранее.
Обращение к разработчику — это не признание слабости администратора. Это нормальная часть развития Wagtail-сайта.
Администратор отвечает за содержание. Разработчик отвечает за инструменты, которые позволяют это содержание удобно, безопасно и аккуратно публиковать.
Обычно нет. Администратор может использовать уже настроенные блоки, а новый тип блока добавляет разработчик. Это связано с тем, что блок должен работать не только в админке, но и на публичной странице сайта.
Потому что разные типы страниц могут иметь разные наборы доступных блоков. Например, страница услуги, статья блога и главная страница могут быть устроены по-разному.
Не обязательно. Возможно, блок не был предусмотрен для этой страницы или для проекта в целом. Сначала стоит проверить похожие страницы и доступные блоки.
Иногда можно, если задача простая и разовая. Но сложные блоки лучше не собирать вручную: так можно нарушить дизайн, адаптивность и единый стиль сайта.
Когда формат нужен регулярно, должен выглядеть одинаково на разных страницах и неудобно собирается из существующих элементов. Особенно если блок влияет на заявки, навигацию, продажи или качество подачи информации.
Нужно описать, где нужен блок, зачем он нужен, какие поля должны быть внутри, как он должен выглядеть и как часто будет использоваться. Полезно приложить ссылку на страницу, скриншот или пример похожего блока. Техническую реализацию описывать не нужно.