Что делать, если нужного блока нет в админке Wagtail

Если в админке Wagtail нет нужного блока, это не всегда ошибка. Чаще всего набор блоков зависит от типа страницы, структуры конкретного сайта и решений, которые были заложены при проектировании и разработке.

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

12 мин чтения2 535 словБаза знаний Wagtail
Что делать, если нужного блока нет в админке Wagtail

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

Если нужный формат повторяется регулярно, лучше не собирать его вручную из текста, картинок и пробелов. Правильнее описать задачу и добавить отдельный управляемый блок.

Почему нужного блока может не быть

В Wagtail набор блоков обычно не универсальный для всего сайта. Он зависит от того, как разработан конкретный проект.

На одном сайте редактор может видеть текстовые блоки, изображения, галереи, документы и FAQ. На другом — карточки услуг, блоки преимуществ, отзывы, тарифы и подборки материалов. На третьем сайте набор будет совсем другим, потому что у проекта другие задачи.

Это нормальная логика Wagtail. CMS не навязывает всем одинаковую админку, а позволяет собрать её под структуру сайта, редакционные процессы и бизнес-задачи.

Блок не был предусмотрен при разработке сайта

Самая частая причина простая: нужный блок не был заложен при разработке.

Например, на этапе запуска сайта были нужны только обычные текстовые блоки, изображения и документы. Через несколько месяцев команда решила, что на страницах услуг хорошо бы добавить блок с преимуществами, иконками и короткими описаниями. Если такого блока раньше не было в задаче, он сам в админке не появится.

Это не поломка. Это значит, что сайт вырос до новой потребности.

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

У разных типов страниц могут быть разные блоки

В Wagtail разные страницы могут иметь разные наборы блоков.

Например, у страницы услуги может быть один набор: текст, преимущества, этапы работы, форма заявки. У статьи блога — другой: текст, изображение, цитата, таблица, FAQ. У главной страницы — третий: промо-блок, подборки, баннеры, карточки направлений.

Это делается не для того, чтобы усложнить жизнь редактору. Наоборот, такая логика помогает не смешивать разные задачи.

Если дать всем страницам все возможные блоки, админка быстро превратится в склад без подписей: вроде всё есть, но найти нужное невозможно, а использовать правильно — ещё сложнее.

Если блок есть на одной странице, это не означает, что он автоматически должен быть доступен на любой другой. Подробнее эту тему стоит раскрывать отдельно — в статье о том, почему разные страницы Wagtail имеют разные наборы блоков.

Ограничение может быть сделано специально

Иногда блок отсутствует не потому, что о нём забыли, а потому что его сознательно ограничили.

Например, крупный промо-блок может быть уместен на главной странице, но странно смотреться внутри обычной новости. Блок тарифов может быть нужен на странице услуги, но не нужен в разделе «О компании». Сложная галерея может быть полезна в портфолио, но лишняя в короткой информационной статье.

Такие ограничения защищают сайт от хаоса.

Редактору кажется: «Дайте мне все блоки, я сам разберусь». На практике это часто заканчивается страницами, которые выглядят по-разному, нарушают дизайн и усложняют поддержку. Wagtail хорош именно тем, что позволяет сделать редактору не бесконечный набор кнопок, а понятный рабочий инструмент.

В проекте могут быть ограничения по ролям или разделам

Иногда вопрос связан с правами пользователя или настройками раздела. Один пользователь может редактировать только новости, другой — страницы услуг, третий — документы или раздел базы знаний.

Обычно права доступа больше связаны с разделами, страницами и действиями, чем с отдельными блоками. Поэтому не стоит сразу считать, что проблема именно в правах. Чаще причина в типе страницы и наборе блоков, который заложен в проекте.

Если вы уверены, что нужный блок должен быть доступен, но вы его не видите, стоит уточнить у администратора проекта или технического специалиста.

Главная задача проверки — понять, с какой ситуацией вы столкнулись.

Блока может не быть вообще. Блок может называться иначе. Блок может быть доступен только на другом типе страницы. Или задача может решаться уже существующим блоком, просто не самым очевидным.

Паниковать не нужно. В админке Wagtail отсутствие блока чаще означает не «всё сломалось», а «для этой задачи пока не предусмотрен отдельный инструмент».

Когда можно использовать существующие блоки

Не каждая задача требует разработки нового блока.

Если нужно добавить обычный текст, короткое пояснение, изображение, ссылку, небольшой список или документ, скорее всего, достаточно уже существующих блоков.

Например, для простого пояснения под заголовком не нужен отдельный сложный блок. Для ссылки на PDF можно использовать текстовый блок или блок документа, если он предусмотрен в проекте. Для небольшой иллюстрации подойдёт блок изображения.

Но здесь есть важная граница.

Если вы начинаете использовать пустые строки для отступов, таблицы для имитации карточек, скриншоты вместо нормального текста или вручную копируете сложную конструкцию с другой страницы, лучше остановиться. Это уже не редактирование контента, а попытка заменить разработку ручной сборкой.

Такой способ может выглядеть приемлемо в редакторе, но плохо работать на сайте. Особенно на мобильных устройствах.

В Wagtail лучше использовать блоки по назначению. Текстовый блок — для текста. Изображение — для изображения. Документ — для документа. А если нужен сложный повторяемый формат, его стоит оформить как отдельный управляемый блок.

Когда лучше сделать новый блок

Новый блок нужен не всегда. Но есть ситуации, когда без него сайт начинает развиваться криво.

СитуацияМожно ли решить без разработкиЧто лучше сделать
Нужно добавить обычный текстДаИспользовать текстовый блок
Нужно разово добавить изображение или ссылкуОбычно даПроверить существующие блоки
Один и тот же формат нужен на многих страницахНежелательно вручнуюСделать отдельный блок
Нужны карточки с заголовками, текстами, иконками и ссылкамиОбычно нетПоставить задачу на новый блок
Блок влияет на заявки, переходы или продажиЛучше не собирать вручнуюСпроектировать и разработать аккуратно
Разные редакторы собирают один формат по-разномуНет, будет хаосСтандартизировать блок
Для нового раздела нужны повторяемые блоки: карточки, FAQ, CTA, документыЧастичноОбсудить доработку структуры и блоков

Новый блок стоит делать, если формат будет использоваться регулярно. Например, на сайте появляются страницы услуг, и на каждой нужна одинаковая структура: преимущества, этапы работы, документы, FAQ и форма заявки.

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

Примеры блоков, которые часто имеет смысл добавлять в Wagtail-проект:

  • блок преимуществ;
  • FAQ;
  • CTA-блок;
  • карточки услуг;
  • этапы работы;
  • галерея;
  • таблица характеристик;
  • блок отзывов;
  • подборка связанных материалов;
  • блок документов;
  • блок тарифов;
  • блок команды.

Если такой блок нужен один раз, можно подумать. Если он нужен на десяти страницах, думать уже поздно — пора проектировать нормально.

Почему не стоит собирать сложный блок вручную

Главная ошибка редактора — попытаться собрать отсутствующий блок из того, что есть под рукой.

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

Проблема не в том, что редактор плохо старается. Проблема в том, что инструмент не предназначен для такой задачи.

Ручная сборка сложных блоков приводит к нескольким проблемам.

Страница может плохо выглядеть на мобильных устройствах. То, что кажется ровным на большом экране, легко разваливается на телефоне.

Нарушается единый стиль сайта. Один и тот же блок на разных страницах начинает выглядеть по-разному.

Контент становится сложнее поддерживать. Следующий редактор не понимает, что здесь можно менять, а что лучше не трогать.

Появляются ошибки в ссылках, изображениях, отступах и заголовках.

Сайт теряет аккуратность. Это заметно не сразу, но через несколько месяцев такие ручные решения превращаются в редакционный чердак: всё вроде нужное, но лучше не открывать без фонарика.

Если один и тот же блок приходится каждый раз собирать руками, это уже не редакторская задача, а кандидат на доработку сайта.

Как описать задачу на новый блок разработчику

Администратору не нужно знать, как новый блок будет устроен внутри Wagtail. Не нужно писать техническое задание языком разработчика, упоминать код, модели или шаблоны.

Нужно описать задачу с точки зрения сайта и редактора.

В хорошем описании нового блока стоит указать:

  1. Где нужен блок: на каких страницах или в каком разделе сайта.
  2. Для чего он нужен: какую задачу решает для пользователя и редактора.
  3. Как часто он будет использоваться.
  4. Какие элементы должны быть внутри: заголовок, текст, изображение, иконка, ссылка, кнопка, файл, список.
  5. Какие поля должны быть обязательными, а какие можно оставить необязательными.
  6. Нужно ли добавлять несколько элементов внутри блока. Например, несколько карточек, вопросов, этапов или документов.
  7. Как должен выглядеть блок на странице.
  8. Есть ли пример на текущем сайте или на другом сайте.
  9. Нужно ли перенести уже созданный контент в новый блок.
  10. Кто будет использовать блок: администратор, редактор, маркетолог, отдел продаж.

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

Главное — описать не техническую реализацию, а смысл.

Плохая постановка задачи:

«Добавьте красивый блок для преимуществ».

Разработчик после такой фразы понимает примерно столько же, сколько врач после сообщения «что-то болит». Вроде направление ясно, но лечить пока рано.

Хорошая постановка задачи:
«Нужен блок «Преимущества услуги» для страниц услуг. В блоке должны быть общий заголовок, короткое описание и от 3 до 6 карточек. В каждой карточке: иконка, заголовок и текст до 150 символов. Редактор должен уметь менять порядок карточек и добавлять новые без помощи разработчика».

Такое описание уже можно обсуждать, оценивать и превращать в задачу на разработку.

Пример: нужен блок преимуществ для страницы услуги

Представим обычную ситуацию.

Редактор готовит страницу новой услуги. На странице нужно показать четыре преимущества: быстрая обработка заявки, персональный менеджер, прозрачные этапы работы и поддержка после запуска.

В админке есть текстовый блок, изображение и кнопка. Отдельного блока «Преимущества» нет.

Можно пойти плохим путём: вручную добавить заголовки, вставить иконки как изображения, написать тексты списком, выровнять пустыми строками и надеяться, что всё будет выглядеть прилично.

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

Хороший путь — описать новый блок.

Например:

«Нужен блок «Преимущества услуги» для страниц услуг. В блоке должны быть общий заголовок, короткое описание и от 3 до 6 карточек. В каждой карточке: иконка, заголовок и текст до 150 символов. Блок должен быть доступен на страницах услуг. Редактор должен уметь менять порядок карточек и добавлять новые без помощи разработчика».

После разработки редактору не нужно будет каждый раз изобретать оформление. Он просто заполнит поля: заголовок, описание, карточки, иконки и тексты.

Такой блок сохраняет единый дизайн, ускоряет работу, снижает риск ошибок и делает сайт понятнее для команды.

Что делает разработчик при добавлении нового блока

Новый блок — это не просто ещё одна кнопка в админке. Это управляемый элемент сайта, который должен быть удобен редактору и корректно отображаться для посетителя.

Обычно разработчик:

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

Иногда задача действительно небольшая. Иногда новый блок требует дизайна, вёрстки, согласования поведения на разных экранах и проверки на уже существующих страницах.

После добавления блока его стоит проверить на черновой или тестовой странице: посмотреть, удобно ли заполняются поля, корректно ли всё отображается на компьютере и мобильном экране, не ломается ли страница при разном количестве элементов.

Не стоит воспринимать добавление блока как мгновенное «включение настройки». В Wagtail блок — часть системы сайта. Если сделать его аккуратно, он потом долго помогает редакторам. Если сделать наспех, он быстро станет ещё одной маленькой проблемой в админке.

Частые ошибки

  • Считать отсутствие блока поломкой сайта

Если нужного блока нет, это не всегда ошибка. Возможно, блок просто не предусмотрен для этого типа страницы или для проекта в целом.

Сначала стоит проверить доступные блоки, тип страницы и похожие страницы сайта.

  • Собирать сложный блок вручную

Это самая частая ошибка. Редактор пытается заменить отсутствующий блок текстом, картинками, таблицами и пустыми строками.

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

  • Использовать текстовый блок не по назначению

Текстовый блок подходит для текста: абзацев, заголовков, списков, простых ссылок.

Но он не всегда подходит для карточек, сеток, CTA, галерей, FAQ, тарифов и других сложных элементов. Если текстовый блок превращается в ручной конструктор, значит, задачу стоит пересмотреть.

  • Просить «просто добавить красивый блок»

Фраза понятная, но бесполезная для разработки. Разработчику нужно понимать, где блок будет использоваться, какие поля нужны, кто будет его заполнять и как он должен выглядеть на странице.

Чем точнее описана задача, тем меньше недопонимания.

  • Делать новый блок ради разовой мелочи

Не каждый разовый элемент нужно превращать в отдельный блок. Если задача простая, не повторяется и спокойно решается существующими средствами, лучше не усложнять админку.

Хорошая админка — это не та, где есть всё на свете. Хорошая админка — та, где есть нужное и нет лишнего.

  • Не проверять другие типы страниц

Иногда нужный блок уже есть, но доступен только на другом типе страницы.

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

Когда обращаться к разработчику

Администратор может многое сделать сам: выбрать доступный блок, заполнить поля, добавить текст, изображение, ссылку или документ, проверить страницу перед публикацией, найти похожий блок и подготовить описание задачи.

Но есть задачи, которые относятся к разработке.

К разработчику стоит обращаться, если нужен новый тип блока, нужно изменить внешний вид существующего блока, добавить новые поля, сделать карточки, FAQ, галерею, CTA или другой управляемый формат.

Также разработчик нужен, если блок должен быть доступен на разных типах страниц, если требуется автоматическая подборка материалов, если блок связан с формой, CRM, каталогом или другой системой.

Ещё один важный сигнал — редакторы регулярно обходят ограничения вручную. Если команда постоянно собирает один и тот же формат из случайных элементов, значит, сайту не хватает нормального инструмента.

Иногда вопрос шире, чем один новый блок. Если для нового раздела нужна особая структура, свои поля, свой набор блоков и отдельная логика вывода, возможно, речь уже о новом типе страницы. Это лучше обсуждать с разработчиком или командой сопровождения заранее.

Обращение к разработчику — это не признание слабости администратора. Это нормальная часть развития Wagtail-сайта.

Администратор отвечает за содержание. Разработчик отвечает за инструменты, которые позволяют это содержание удобно, безопасно и аккуратно публиковать.

FAQ

Обычно нет. Администратор может использовать уже настроенные блоки, а новый тип блока добавляет разработчик. Это связано с тем, что блок должен работать не только в админке, но и на публичной странице сайта.

Потому что разные типы страниц могут иметь разные наборы доступных блоков. Например, страница услуги, статья блога и главная страница могут быть устроены по-разному.

Не обязательно. Возможно, блок не был предусмотрен для этой страницы или для проекта в целом. Сначала стоит проверить похожие страницы и доступные блоки.

Иногда можно, если задача простая и разовая. Но сложные блоки лучше не собирать вручную: так можно нарушить дизайн, адаптивность и единый стиль сайта.

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

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