Опубликован опрос для разработчиков тем по поводу JSON файлов и блочных тем WordPress

В WordPress 5.8 была введена система выбора опций для тем, позволяющая настраивать параметры блоков, стили, шаблоны и т. д. Делается это с помощью нового файла theme.json, который разработчики могут помещать в корень своих папок с темами. Энн МакКарти, руководитель программы FSE Outreach Program, опубликовала опрос для получения отзывов разработчиков о данной возможности.

«Поскольку этот механизм является первым шагом на пути к общей системе стилей в WordPress, важно услышать мнение всех, кто в настоящее время пользуется theme.json. Нам надо знать, как люди работают с этим инструментом, что еще можно включить в ядро в будущем», – отметила Энн в анонсе.

Опрос открыт для всех авторов тем, которые пользовались theme.json. Это поможет собрать воедино все отзывы и пустить разработку в правильном направлении.

Я много работал с этой системой за последние несколько месяцев, а потому мне было что сказать. Да и в целом мне нравится участвовать в опросах, связанных с WordPress. Заодно я смог поделиться своими мыслями по поводу текущего состояния theme.json с точки зрения разработки.

Ниже приведены мои ответы на вопросы анкеты.

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

Опыт разработчика

Первый вопрос достаточно простой. Каков ваш опыт работы с блочными темами и theme.json. Есть четыре варианта ответа (и вариант «другое»):

• Я создавал и запускал блочные темы.
• Я экспериментировал с разработкой блочных тем.
• Я использовал theme.json в классических темах.
• Я использовал блочные темы, но не сталкивался с их разработкой.

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

Начало использования theme.json и блочных тем

Второй вопрос связан с тем, как вы начали работать с блочными темами и theme.json. Тут можно выбрать пункты: форк существующей темы, использование пустой темы Empty Theme или написание темы с нуля.

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

Я планирую выпустить ее бесплатно когда-нибудь в будущем. В основном мои ожидания следующие:

• Финальная проработка блока Navigation.
• Разбиение блока Post Author на более мелкие блоки.
• Надежный набор блоков, связанных с комментариями.
• Блок Post Featured Image с опцией выбора размера изображения.

Если бы эти вопросы были решены, я бы выпустил бета-версию своей темы уже сегодня.

Шаблоны и участки шаблонов

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

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

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

Система блочных шаблонов так не работает. Получается, разработчики должны отказаться от принципа Don’t Repeat Yourself (DRY).

К примеру, если дизайнер раньше хотел вывести разные участки хэдера для записей и страниц, ему надо было создать только шаблон header-page.php или header-post.php в традиционных темах. Но поскольку система блочных шаблонов отличается, теперь дизайнерам надо создавать уже два шаблона верхнего уровня, single.html (для записи) и page.html, для достижения той же самой цели.

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

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

Я также ответил на вторую часть вопроса и перечислил наиболее часто используемые мною участки шаблонов (с разбивкой по иерархии):

• Header
• Content
• – Loop
• – Sidebar
• Footer

Определение цветов

В следующем разделе задается вопрос, как авторы тем определяют слаги цветовой палитры в theme.json. Вы не поверите, но наименование цветов – это «горячая точка» в мире тем за последние годы. Разработчики обычно сходятся в названии background и foreground цветов.

В 2018 году Мортен Рэнд-Хендриксен открыл тикет по поводу стандартизации схемы наименования цветов. Это было далеко не первое обсуждение и не последнее. Проблема, поднятая в тикете, заключалась в слагах для цветов в системе (особенности задания палитр цветов в темах). Как только пользователь выбирает предустановленный цвет, слаг тут же прописывается в коде. Достаточно переключиться на другую тему с другими слагами – и старые цвета исчезнут. Автоматического перехода на цвета новой темы не произойдет.

Я использую семантические имена, которые чем-то напоминают систему, принятую в Tailwind CSS-фреймворке. Вместо red-medium (дескриптивное имя) я использую primary-500 (семантическое имя). Семантический подход позволяет авторам тем определять набор цветов, которые будут обновляться всякий раз при переключении темы пользователем.

Естественно, имеются и другие подходы. Даже разработчики, предпочитающие семантическое наименование, не всегда согласны с той же системой. Я описал свой подход более подробно в свежем GitHub-тикете. Также у меня есть theme.json Gist для тех, кто хочет все это попробовать.

Другие настройки JSON

В опросе есть пункт: какие еще настройки используют разработчики тем (помимо цветов и типографики)? Обычно здесь я отвечаю, что использую все доступные параметры и опции.

Одна из настроек, для которой в данный момент нет предустановок в WordPress – это глобальные отступы (spacing). Большинство авторов тем обычно используют одно значение для всех вертикальных полей (отступы между блоками и элементами). Часто задаются базовые вертикальные и горизонтальные отступы (padding).

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

Параметры и стили для каждого отдельного блока

В этом разделе был задан простой вопрос с ответом «да/нет»: включили ли авторы тем параметры или стили для отдельных блоков в свои файлы theme.json? Я решил поделиться своими мыслями в поле комментариев чуть ниже.

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

Указание CSS в JSON, на мой взгляд, является неправильным. В настоящий момент можно задавать только несколько настраиваемых стилей, а потому все, что выходит за рамки этого, нужно будет все равно прописывать в CSS-файле. Здесь мы видим проблему: CSS-код темы разбит на theme.json и отдельные CSS-файлы. Это затрудняет поддержание кодовой базы.

Изначально я пробовал настраивать стили для блоков и элементов через theme.json. Но потом я вернулся обратно к заданию стилей через CSS-файлы. Это выглядит более естественным, плюс у меня есть бонус в виде понятных мне инструментов. Прямо сейчас я не могу представить себе ситуацию, когда бы я захотел вернуться к стилям в theme.json.

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

Другие отзывы: уровень PHP

Я уже говорил об этом ранее, но повторю еще раз. Нам нужен уровень PHP для системы конфигурирования theme.json. Уже сейчас есть открытый тикет для данной проблемы.

У такой системы будет два основных преимущества. Наличие PHP API для связывания воедино конфигурации будет более естественным шагом для разработчиков традиционных тем. Это станет демонстрацией доброй воли со стороны разработчиков ядра/Gutenberg, ведь в таком случае авторам тем будет гораздо проще освоить функционал FSE при помощи уже знакомого языка программирования.

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

Источник: wptavern.com

Источник: oddstyle.ru