В 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