Wagtail - это популярная CMS на основе Django. Django предоставляет огромные возможности - с его помощью созданы не только сайты, но и, например, популярный веб-сервис комментариев disqus, веб-сервис хранения git репозиториев bitbucket и многое другое. На django можно создать все что угодно.
Wagtail предоставляет пользователям новые, построенные с помощью Django, абстракции. Можно провести следующую аналогию: если django предоставляет вам молоток, пилу, гвозди и деревянные доски, то Wagtail сразу дает готовые столы, стулья и прочую мебель сколоченную из того, что есть в django. Для своего проекта вы конечно можете собрать необходимую мебель сами, используя только django, но во многих случаях будет гораздо проще и быстрее взять что-то готовое из Wagtail.
Из комментариев в интернет кажется, что многие считают Wagtail надстройкой к админке django, но это далеко не так. В этой статье я расскажу о Wagtail, которую считаю лучшей CMS и приведу некоторые абстракции, предоставляемые Wagtail.
Кто стоит за Wagtail
История Wagtail начинается с 2014 года, когда британская компания Torchbox разработала сайт для Королевского колледжа искусств. Если пройти на сайт с установленным расширением Wappalyzer, можно убедиться, что заведение по сей день использует Wagtail. Изначально планировалось, что Wagtail станет open source проектом, каким он и остается по сей день. Torchbox ведет разработку своей CMS по настоящее время и предлагает платные услуги по поддержанию и созданию сайтов на Wagtail.
Сейчас Wagtail используют такие организации как Mozilla Foundation, Nasa, Британский минздрав, Калтех, google в официальном туториале для своей облачной платформы устанавливает Wagtail на App Engine и многие другие. Если пройти по ссылкам из предыдущего предложения, опять же можно проверить Wappalyzer или любым другим инструментом, что сайты действительно используют Wagtail CMS.
На момент написания статьи, гитхаб репозиторий Wagtail имеет чуть больше 11 тысяч звезд и в разработке успело поучаствовать 496 человек, репозиторий очень активный. Для сравнения репозиторий Django CMS - еще одной CMS написанной с использованием Django имеет почти 8.5 тыс звезд и 440 участников а репозиторий Wordpress имеет 15.5 тыс звезд и 63 участника. Команда Wagtail регулярно выпускает новые версии по заданному расписанию, например следующая версия 2.15 ожидается 1 ноября 2021.
Основные идеи Wagtail
Разработчик подошли к созданию Wagtail с некоторыми ключевыми идеями в голове, которые они назвали "Дзен Wagtail" по аналогии с "Дзен Питона". Вот мой пересказ Дзена Wagtail:
Во-первых на Wagtail нельзя создать сайт без программирования. Если вам нужно что-то простое и быстро, лучше не тратить время на Wagtail - не забивайте гвозди микроскопом, установите готовую CMS и настройте ее мышкой. Wagtail актуален для создания проектов, которые могут иметь много абстракций, сложные зависимости между ними, несколько пользователей с различными ролями и т.п.
Создание и поддержание сайта это общая работа нескольких людей. В Wagtail удобно и необходимо разделять обязанности разработчика, дизайнера, администратора сайта и автора, подготавливающего материалы на сайт.
Авторы материалов для сайта должны иметь удобный и быстрый способ добавлять свои идеи/мысли/новости на сайт. Авторы не должны писать код на css или html. Дизайн и контент должен быть отдельно.
Лучшим инструментом для разработчика сайта является язык программирования. Wagtail предполагает, что разработчик сам напишет какие-то нужные для сайта дополнения.
Некоторые возможности Wagtail
Страницы
Одной из важных абстракций, предоставляемых Wagtail является страница - Page. Страница предоставляет кучу полезного функционала из коробки - черновик, можно сохранять все версии страницы в базе данных (по мере их редактирования), дата публикации, дата изменения и много другое. Можно создать сколько угодно отдельных типов страниц, наследуя от Page. Например, отдельные классы для страниц блога, новостей, сотрудников и т.п. В каждом из таких типов можно задать, какой контент должен быть на странице - например, просто текст, изображения, видео... или все вместе.
Страницы организованы в виде графа - каждая страница может быть дочерней или родительской к другой странице, что можно указать в коде. Например, можно сделать страницу "Люди" /people/, в которой будет написано какой классный коллектив работает в компании. Дочерними страницами для страницы "Люди" можно сделать индивидуальные страницы сотрудников например /people/ceo, /people/cto... Все это делается в Wagtail в пару строк кода.
Управлять содержимым страниц можно только из админ панели wagtail.
StreamField
Еще одним важным инструментом является StreamField. StreamField позволяет создать контент из блоков - также как, например, пишутся статьи на хабре, vc, vk - короче это уже стало стандартом. Ваша страница это просто набор блоков - блок изображение с подписью, блок текст, блок видео... В Wagtail можно создать собственные виды блоков. Например, можно создать блок для карусели картинок, как в vk.
Картинки
Wagtail дает возможность обрезать картинки как угодно, в интерфейсе можно указать фокусную точку на картинке и Wagtail будет стремиться показать ее на страницах с изображением. В документации есть также инструкция как настроить Wagtail на распознавание отдельных элементов на картинках (например лиц, кошечек, машинок и т.п.) и в дальнейшем обрезать картинки, чтобы распознанная часть попадала куда нужно.
API
Нужна безголовая (Headless) CMS? Нет проблем! REST API в Wagtail доступно практически по умолчанию (пара строк кода, скопированных из документации). Если нужно что-то круче - graphql - есть пост от Torchbox с кодом и инструкциями какие пакеты нужно установить.
Другие возможности
Админ интерфейс Wagtail легко настраивается - можно добавить новые элементы меню, поменять логотип, поменять цвета. Админ интерфейс адаптивный - нормально выглядит на смартфоне, компьютере, планшете и т.п. Еще в Wagtail легко создавать сложные таблицы, из коробки доступен ставший стандартом elasticsearch, есть разделение доступа между пользователями а также группами пользователей и многое другое.
Освоить Wagtail
Предположу, что написанное выше звучит очень абстрактно и чтобы разобраться нужно посмотреть примеры и пописать код.
У Wagtail отличная документация, хотя на ответах со stackoverflow я не раз сталкивался с примерами недокументированных возможностей. Кстати на stackoverflow у Wagtail отличная поддержка. На один мой вопрос даже ответил сотрудник Torchbox Matt Westcott - один из ключевых разработчиков Wagtail.
Отличные уроки по Wagtail на английском подготовил Kalob Taulien:
Доступных материалов на русском, к сожалению, не так много. Все, что я смог найти это:
На хабре есть один старенький туториал из трех частей по запуску CMS (раз, два, три). Возможно, что-то оттуда уже устарело, но, попробовать запустить можно.
Туториал https://python-scripts.com/wagtail - надеюсь, автор написал тот пост не ради рефералки на хостинг.
Пользуясь случаем, не могу не прорекламировать блестящие уроки на youtube, отснятые моей скромной персоной:
Заключение
Видя какой путь прошел Wagtail, и как он развивается сейчас, уверен, что данная CMS будет только процветать, ведь ее поддерживают настоящие профи, которые зарабатывают деньги, делая Wagtail лучше, ей пользуются самые передовые организации и IT гиганты, в ней есть крутые возможности из коробки.
Комментарии (11)
censor2005
12.10.2021 08:35+2Напомнило мне Drupal 7, когда я на нём еще писал. Тоже позволяет создавать абстракции на основе Страниц, и тоже требует написания кода для расширения функционала. Интересно, как сейчас дела у Drupal? Очень он мне нравился в своё время
nivorbud
12.10.2021 08:54+2Я уже лет пять-шесть как полностью перешел на разработку сайтов на wagtail. Для меня это идеальная система. Да, мгновенно сайт не поднимешь, надо сначала продумать структуру типов контента и блоков, связи между ними и т.д. и потом всё это описать на питоне. Но при этом... большинство вещей делается максимально гибко и буквально описывается несколькими строками кода. Т.е. сайт создается из кубиков, причем кубики легко можно самостоятельно создавать.
И главное механизм наследования можно использовать на всю катушку. Например, я создаю базовый тип страницы с общими заголовочными полями и методами (например формирования хлебных крошек и пр.). Далее создаю контентные типы страниц, наследуясь от базового типа. И т.д.
Механизм StreamFields вообще шикарен: редактор сайта в админке создает контент также из кубиков-блоков, причем блоки вы сами можете создавать (их представление через шаблоны, их логику поведения - всё на питоне). Эти контентные блоки могут быть весьма сложными, могут содержать в себе другие блоки... Т.е. в итоге редактор сайта в админке не в визуальном редакторе произвольно создает контент (что потом вызывает большие проблемы), а создает контент из блоков (а блоки сами знают, как себя представлять, как обрабатывать введенные данные). Например, вам надо в статьи часто вставлять документы, имеющие определенную структуру (превью, название, поля - кому, от кого и т.д.) - вы просто создаете сримфилд-блок с необходимыми полями необходимых типов, создаете шаблон и стили. Всё, теперь редактор просто создает блок и заполняет поля. А как это будет выводиться на сайте, как стилизоваться и пр. - это уже не проблема редактора, редактор работает только с данными, а как они будут выводиться, как будут выравниваться и пр. - об этом вообще не должен думать.
Еще нравится гибкость древовидной структуры: парой строчек кода вы указываете какие страницы (какого типа) могут быть вложены в страницы другого типа. Именно такая гибкость не дает сходу поднять сайт. Одно и то же можно реализовать множеством способов. Поэтому сначала надо подумать, какую структуры (типы данных, связи, структуру вложенности) выбрать.
Есть некоторые вопросы к производительности, но около миллиона структурированных страниц тянет. Для поиска использую elasticsearch. Более миллиона страниц я бы не стал в дереве размещать, лучше ограничиться джанговскими моделями (вагтэйл позволяет без проблем сделать тип страницы, которая будет свои данные по урлу тянуть из джанговской модели).
danSamara
13.10.2021 09:25+1Судя по миграции:
migrations.CreateModel( name='PageRevision', fields=[ #... ('content_json', models.TextField()), #... ], ),Wagtail хранит весь контент, по сути, в блобах - текстовое поле с JSON. Таким образом взаимодействие с отдельными полями контента будет затруднено - каждый виджет имеет свой формат. Как будет выглядеть SQL запрос выборки значений из страниц с вложенными streamfields и произвольным наполнением контента в них, страшно представить. Но, скорее всего, никак не будет выглядеть - вам придётся строить отдельный бэкенд обработки полей, как это сделано для поиска - для дублирования информации в отдельных таблицах и уже нормальной работой по ним. Поэтому использование elasticsearch "из коробки" выглядит ни разу не фичей, а провалом архитектуры.
Не вижу никаких преимуществ по сравнению с любым SSG, которые позволяют гибко настраивать поля и имеют собственную админку для редактирования контента, например Pelican, если мы говорим про Python или множество других на разных ЯП.
Ещё непонятно как использовать streamfields на фронте - например я хочу сделать сайт с рецептами - чтобы пользователи могли добавлять рецепты, используя streamfields с ограниченным набором кастомных полей (текст, картинки, тэги, ингредиенты и т.п.). Админку, я, во-первых, им давать не хочу, во-вторых, это всё должно быть в интерфейсе сайта, по фэншую. Ну и плюсом надо построить списки по срезам: тэги, ингредиенты, лента. С поиском понятно, а как с остальным решаются вопросы в Wagtail?
nivorbud
13.10.2021 12:13+1Поля типа Streamfild надо использовать не для любых текстовых полей, а для объемных универсальных полей как замену навороченному визуальному редактору (там ведь тоже каша - из html-кода). Но в отличие от визуального редактора, акцент сделан на работу с данными, а не на оформление.
А на фронте я бы не стал использовать streamfield, там достаточно обычных полей. Ведь например в вашем примере с рецептами структура рецептов заранее известна, там гибкость стримфилда не нужна. Да и в бэкэнде я бы наверно для рецептов не задействовал стримфилд.
Стримфилд - это только одна из фич вагтейла. Ее далеко не всегда имеет смысл использовать, т.к. программно работать с ней действительно сложнее.
danSamara
13.10.2021 13:42+1Ведь например в вашем примере с рецептами структура рецептов заранее известна, там гибкость стримфилда не нужна.
На мой взгляд, очень удобно было бы использовать именно sf на фронте - есть рецепт и пользователь его наполняет: выбрал блок видео - добавил, выбрал текст - добавил, фото, снова видео, блок ингредиентов для теста, блок ингредиентов для начинки и т.д. - самое оно!
Да и в бэкэнде я бы наверно для рецептов не задействовал стримфилд.
Тогда зачем Wagtail? Джанга сама всё умеет. Там тоже есть вложенные формы. Да, не в такой удобной обёртке, но всё же.
mihrutochka Автор
13.10.2021 12:35Действительно, StreamFields это json и это накладывает некоторые ограничения. Редактирование и создание StreamFields можно осуществлять только из админки Wagtail, беспокоиться об отдельном бэкенд не нужно - Wagtail сам выводит StreamFields в нужном виде - либо как html по заданному шаблону, либо через API в json (все опять же решается парой строк кода из документации). API Wagtail. которые из коробки, доступны только для чтения. Тэги есть - Wagtail использует django-taggit.
danSamara
13.10.2021 13:54+1Вот мне в этом случае и непонятна целевая аудитория подобного решения, она получается очень узкой - начинающие разработчики на Django, которым надо быстро поднять простой сайт с небольшим набором сложно-сочинённых страниц и чтобы не городить весь этот огород ради небольшого объёма очень удобно использовать streamfield.
Причём, надо заметить, матёрые разрабы на Django уже имеют привычный набор батареек, который позволяет быстро поднять "стандартный сайт".
Здесь было бы уместно упомянуть Django CMS - у неё тоже есть подход к редактированию страниц блоками (или виджетами), но они являются более тонкой прослойкой к Django и не изобретают собственную структуру хранения данных, скорее строят свой редактор контента, который, кстати работает "внутри сайта", без отдельной админки.
mihrutochka Автор
14.10.2021 00:37+1Wagtail это не только streamfield. Если Вы не планируете использовать (давать пользователям доступ) админ панель, Wagtail Вам не нужен. Вам нужен хороший API и фронт. Написать такой апи и фронт, на мой взгляд, много работы. Добавьте к этому коллекции изображений и документов, управление доступом к ним различным пользователям и группам, обрезка изображений, черновики и версии страниц и вот Вы получаете весьма сложную структуру, для написание работающей и покрытой тестами версии которой нужно потратить много времени. На Wagtail это можно сделать гораздо быстрее, и значительно меньшим объемом кода. При этом вообще не заморачиваться над фронтом для создания и редактирования страниц/коллекций...
danilovmy
13.11.2021 21:19Спасибо за статью, заглянул и в уроки, несколько посмотрел.
Подумал что нашел серебряную пулю... но увы. Для специфичных задач трясогузка не прокатит: мультитеннантность не доделали. Поскольку они используют Django.contrib.sites - то я знаю как допилить, даже статью писал об этом. Но так хотелось готового решения... :'(
Мультиязычность через modeltranlation если в проекте 32 языка замедлит каждое языковое дерево в Pages, так ещё и fallback всей страницы из дерева по умолчанию. Fallback только одного поля - ручками делать. Ну и с мультитеннантностью вообще не работает - одному сайт на хинди второму на немецком, а в модели, да и в админке и хинди и немецкий. Админку конечно можно допилить. Переводные Модели - нет.
Некоторые решения выглядят недоделанно. Pages это микс модели и администратора. Что ж они авторегистрацию полей для бэкэнда не сделали? Например по атрибуту поля модели. Модельные поля у них свои. Любой же атрибут могли добавить.
Бэк вагтайла выглядит благороднее винтажной админки чистого Джанго, но до Админ панели здоровой Python-cms (не существует в природе) ещё далеко.
MilashchenkoEA
Судя по всему хороший инструмент, как cms. Чтобы не изобретать велосипед, почему бы и нет. Ещё и на Питоне :)