WordPress 5.8 представил систему выбора тем для настройки параметров блоков, стилей, шаблонов и многого другого. Это делается с помощью нового theme.json файла, который авторы могут помещать в корень своих папок с темами. Энн Маккарти, руководитель программы FSE Outreach Program, ранее сегодня объявила об опросе, чтобы получить отзывы разработчиков об этой функции.
«Поскольку этот новый механизм является ранним шагом к всеобъемлющей системе стилей для будущего WordPress, важно услышать мнение всех, кто в настоящее время theme.json использует этот инструмент, чтобы узнать больше о том, как люди используют этот инструмент и что может иметь смысл включить в Core. вперед », – написала она в объявлении.
Опрос открыт для всех авторов тем, которые использовали его theme.json, что дает им возможность высказать свое мнение на раннем этапе и помочь направить корабль вперед.
Ниже приведены ответы на вопросы опроса – ну, в общем, приведенная в порядок версия.
Примечание. Этот пост ориентирован на разработчиков, и не всегда может понравиться всем нашим читателям.
Опыт
Первый вопрос анкеты довольно простой. Он спрашивает, каков ваш опыт работы с темами строительных блоков или их использованием theme.json. Он предоставляет четыре варианта (и «другой» вариант):
- Я создал и запустил блочные темы.
- Я экспериментировал с темами строительных блоков.
- Я исследовал использование
theme.jsonклассической темы. - Я использовал блочную тему, но еще не создал ее.
Я выбрал первый вариант, потому что я уже создал две темы блоков для семьи и друзей. Это были простые личные сайты, которые я уже поддерживаю бесплатно – честно говоря, мне нужно начать заряжать . Я также работаю над темой, которую надеюсь опубликовать.
Как это начиналось и как продвигается
Второй вопрос касается того, как начали работать с темами блоков и theme.json. Вы можете выбрать между созданием существующей темы, использованием пустой темы или началом с нуля.
Опять же, это одна из тех вещей, где я экспериментировал с каждым направлением, но я не могу вспомнить точную отправную точку. Основная часть моей работы возникла в результате разветвления темы, над которой я последний раз работал в 2019 году.
Я планирую выпустить это как новую тему бесплатно в какой-то момент. Я в основном жду следующего:
- Разработка блока навигации для поселения
- Блок автора сообщения будет разбит на более мелкие блоки
- Надежный набор блоков, связанных с комментариями
- Опубликовать блок избранного изображения, чтобы иметь возможность выбора размера
Я думаю, что смог бы реально выпустить бета-версию своей темы с использованием на свой страх и риск сегодня, если бы эти вопросы были решены.
Шаблоны и части шаблонов
В ходе опроса спрашивалось, какие шаблоны и части шаблонов они всегда включают в свои блочные темы. Появилось поле для комментариев в произвольной форме – наступает на мыльницу…
На данный момент у меня есть отношения любви / ненависти к шаблонам блоков. Статическая природа HTML-шаблонов напоминает мне о более простых временах, когда разработка тем была менее сложной. Однако это также представляет проблему в динамической системе.
Я не могу вспомнить последний раз , когда я построил традиционный, PHP на основе темы с более чем один шаблон верхнего уровня: index.php. Динамические части всегда были внутренностью вещи, то есть частями шаблона. С помощью PHP легко установить некоторую переменную или использовать вызов функции для контекстной загрузки частей шаблона, необходимых для той страницы, которую посетитель в данный момент просматривает на сайте.
Система шаблонов блоков так не работает. По сути, это вынуждает разработчиков нарушать принцип «Не повторяйся» (DRY).
Например, если дизайнер хотел отобразить другую часть шаблона заголовка для страниц и сообщений, ему нужно было бы только создать шаблон header-page.php или header-post.php в традиционных темах. Однако, поскольку система шаблонов блоков отличается, теперь они должны создать два шаблона верхнего уровня, single.html(публикация) и page.html, чтобы выполнить одно и то же.
Это «плохо», потому что авторы темы должны дублировать весь остальной код в каждом из шаблонов верхнего уровня. Невозможно контекстно загружать различные части шаблона.
Чтобы ответить на вопрос: я использую почти все возможные шаблоны верхнего уровня по необходимости.
Я также ответил на вторую часть вопроса и перечислил наиболее часто используемые части шаблона (с разбивкой по иерархии):
- Заголовок
- Контент
– Цикл
– Боковая панель - Нижний колонтитул
content-*.htmlИ loop-*.html части шаблона являются те , с наибольшим количеством вариаций.
Определение цветов
В следующем разделе опроса спрашивается, как авторы тем определяют ярлыки цветовой палитры theme.json. Вы не поверите, но название цветов может быть самой противоречивой темой в тематическом мире за последние годы. Единственные две вещи, о которых обычно договариваются, – это цвета «фона» и «переднего плана».
В 2018 году Мортен Ранд-Хендриксен открыл билет на стандартизацию схемы цветового обозначения темы. Это было не первое обсуждение и не последнее. Проблема, которую он должен был решить, заключалась в слагах для цветов в системе, именно так темы определяют свои палитры. Как только пользователь использует предустановленный цвет, ярлык жестко вставляется в его контент. Переключитесь на другую тему с другими ярлыками, и старые цвета исчезнут и не изменятся автоматически на цвета новой темы.
Я использую семантические имена, которые следуют чему-то, очень напоминающему систему затенения фреймворка Tailwind CSS . Вместо red-medium(описательного) я бы использовал primary-500, например, (семантический). Семантический подход позволит авторам тем определять набор цветов, которые обновляются каждый раз, когда пользователь переключает темы.
Конечно, существуют и другие школы мысли, и даже все, кто предпочитает семантическое именование, не согласны с той же системой. Я описал свой подход более подробно в более позднем тикете GitHub, и у меня есть theme.json Gist для тех, кто может захотеть его попробовать.
Другие настройки темы JSON
Помимо цветов и типографики, в опросе спрашивается, какие еще настройки темы использовали авторы. Это еще один сценарий, в котором я обычно использую все – если есть возможность, я определяю это.
Одним из вариантов использования, для которого в настоящее время нет предустановки WordPress, является глобальный интервал. Большинство авторов тем используют одно значение для большинства вертикальных полей (пробелов между блоками и элементами). Он также часто используется для вертикального и горизонтального заполнения по умолчанию.
Я не уверен, нужен ли мне пресет, потому что я не знаю, как WordPress будет его использовать. Это то, о чем просили другие , и оно используется почти повсеместно. Определение всей системы вокруг него может вызвать головную боль в будущем, но я все же хотел бы увидеть некоторое обсуждение реализации по крайней мере стандартного пресета глобального интервала.
Параметры и стили для каждого блока
Этот раздел опроса представлял собой вопрос типа «да / нет», просто спрашивая, включили ли авторы темы настройки или стили для каждого блока в свои theme.json файлы. Конечно, я оставил несколько дополнительных комментариев позже в необязательном разделе комментариев.
Я доволен системой, когда дело доходит до настроек, которые позволяют пользователям определять, какие функции включены глобально или для каждого блока. Однако я не заинтересован в добавлении стилей через theme.json.
Написание CSS в JSON, о чем мы говорим, кажется неправильным на многих уровнях. В настоящее время он ограничен всего несколькими настраиваемыми стилями, поэтому все, что выходит за рамки этого, в любом случае требует погружения в настоящий файл CSS. Это проблематично, потому что половина кода CSS темы разделена theme.json на отдельный файл CSS. С точки зрения разработки, это усложняет поддержку кодовой базы.
Изначально я начал настройку стилей для блоков и элементов из theme.json. Однако с тех пор я вернул стиль обратно в файлы CSS. Это кажется более естественным, и у меня есть дополнительное преимущество всех инструментов, к которым я привык. Прямо сейчас я не могу представить сценарий, по которому я бы вернулся.
Помимо экономии нескольких байтов кода, я не увидел особых преимуществ в добавлении стилей для большинства вещей через JSON. Может быть, это изменится в будущем, и я стану новообращенным. На данный момент я в основном придерживаюсь CSS.
Другие отзывы: уровень PHP
Я уже говорил это раньше , но стоит повторить. Нам нужен уровень PHP для этой theme.json системы конфигурации. В настоящее время есть открытый билет для решения этой проблемы.
У такой системы есть два основных преимущества. Наличие PHP API для объединения конфигурации будет гораздо более естественным для традиционных разработчиков тем. Я смотрю на это как на оливковую ветвь, демонстрацию добросовестности, которую разработчики ядра / Gutenberg признают, что многим авторам тем будет легче освоить функции FSE с помощью знакомого языка программирования.
Второе преимущество заключается в том, что существует неисчислимое количество идей плагинов для расширения глобальных стилей, редактирования сайта и многого другого, если есть простой способ подключиться к системе JSON темы и перезаписать вещи. Простой крючок для фильтра сделает это безболезненным.
