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