Темы FSE и WordPress: как выглядит MVP?

Джозефа Хейден Чомфоси, исполнительный директор WordPress, опубликовала продолжение своего плана на предстоящий год. Возникли вопросы о том, как выглядел минимально жизнеспособный продукт (MVP) для полного редактирования сайта (FSE), который, как ожидается, будет готов в плагине Gutenberg в апреле. Основная команда также готовится к июньскому запуску FSE в WordPress, когда выйдет WordPress 5.8.

Это кажется высокими целями, но члены сообщества разработчиков WordPress и бизнес-сообщества задались вопросом: «Что такое MVP для FSE?» Это не новый вопрос. Будь то быстрый темп разработки, нарушение связи или большая часть проекта скрыта за слоями проблем GitHub, за этим может быть трудно уследить. Не существует большой веб-страницы, на которой в мельчайших подробностях описывается каждый шаг проекта. Информация может иногда казаться рассеянной. Это может поставить в тупик сторонних разработчиков и владельцев бизнеса, которым нужно знать, чего ожидать при обновлении своих продуктов.

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

«Я думаю, что FSE изменит суть темы и, если она будет реализована должным образом, значительно упростит создание темы, поскольку темы будут намного меньше», — сказал он. «Однако это возлагает на сообщество бремя разработки надежных методов стилизации и соглашений об именах классов и т. п., чтобы стилизация работала везде. В настоящее время я не понимаю, что вообще считается MVP для полного редактирования сайта, и я не вижу никаких дискуссий о том, как это будет работать с темами, специально не созданными для этого, и это меня беспокоит».

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

«И такого нет», — сказал он. «Видение без исполнения — просто галлюцинация».

Хомфоси сказала, что она знала о взаимосвязанности. «Я также вижу, что информация, которую мы опубликовали, не представлена ​​в аккуратном и понятном посте, который помог бы людям принимать правильные решения от имени 39% пользователей Интернета», — сказала она.

Она указала на билет, в котором перечислены шесть (теперь семь) вех. Каждая из этих вех, взятых вместе, показывает, где должен быть FSE для MVP.

«Вместе они определяют архитектуру, которая позволяет выразить полную тему с помощью блоков и редактора, способного настраивать эту тему», — написала она. « MVP должен позволять создавать версию темы Twenty Twenty-One, используя только блоки, без каких-либо знаний в области кодирования. “

Ниже приводится разбивка этапов, которые необходимо выполнить, прежде чем мы увидим первую версию FSE в WordPress:

Этап 1: Инфраструктура и пользовательский интерфейс

Возможно, наиболее важной частью FSE является работающий редактор сайта. Объединение системы шаблонов WordPress в единый пользовательский интерфейс является основой проекта. Базовая инфраструктура управляет тем, как работают шаблоны и их части. На данный момент этот фундамент находится в надежном месте. Все функции, которые основаны на нем, требуют дополнительной работы. Эта веха также включает создание интерфейса редактирования сайта и управление сохранением нескольких сущностей.

Последний этап вехи позволяет пользователям редактировать шаблоны из редактора сообщений, эффективно переключаясь между редактированием контента и дизайна. Программа FSE Outreach недавно протестировала эту функцию, чтобы собрать отзывы после выхода Gutenberg 9.6.

Этап 2: просмотр

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

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

Этап 3: Стиль

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

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

Этап 4: Тематические блоки

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

По общему признанию, мне грустно видеть, что блоки для закладок/ссылок вряд ли будут продвигаться вперед. Хотя эта функция устарела, я все еще ностальгирую по старым добрым дням блогролла. Может быть, это было бы лучше оставить плагин. Возможно, стоит возродить плагин Link Manager.

Этап 5: блок запроса

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

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

Этап 6: Блок навигации

Помимо блока запросов, навигация — это единственный блок, для которого требуется собственная веха. Проблемы с меню навигации преследовали проект WordPress уже более десяти лет. Это одна из самых сложных вещей, чтобы сделать все правильно. Хотя сегодня с навигационными меню в WordPress, как правило, легко работать, их дизайн не настраивается конечным пользователем. Вывод полностью на усмотрение автора темы. Удовлетворение множества возможных дизайнов меню, которые могут захотеть авторы тем, и создание их настраиваемых для конечного пользователя, вероятно, является одной из самых сложных проблем для проекта Gutenberg.

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

Этап 7: Постепенное внедрение

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

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