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

Опубликовано: 2021-07-31

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

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

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

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

Ниже приведены мои ответы на вопросы анкеты — ну, в прибранной версии.

Примечание. Этот пост ориентирован на разработчиков и может понравиться не всем нашим читателям. Я попытался объяснить некоторые вещи в удобной для пользователя терминологии, но могут потребоваться некоторые предварительные знания по разработке тем.

Опыт

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

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

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

Как это началось и как это происходит

Второй вопрос спрашивает, как вы начали работать с блочными темами и theme.json . Есть выбор между разветвлением существующей темы, использованием пустой темы или запуском с нуля.

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

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

  • Разработка навигационного блока, чтобы успокоиться
  • Блок автора сообщения будет разделен на более мелкие блоки.
  • Надежный набор блоков, связанных с комментариями
  • Разместите блок Featured Image, чтобы иметь возможность выбора размера

Я думаю, что я мог бы реально выпустить бета-версию моей темы на свой страх и риск сегодня, если бы эти вопросы были решены.

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

В опросе задавались вопросы о том, какие шаблоны и части шаблонов всегда включают в свои блочные темы. Там было поле для комментариев произвольной формы — наступает на мыльницу…

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

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

Система блочных шаблонов так не работает. По сути, это вынуждает разработчиков нарушать принцип «Не повторяйся» (DRY).

Например, если дизайнер хочет отобразить другую часть шаблона заголовка для страниц и сообщений, ему нужно будет только создать шаблон header-page.php или header-post.php в традиционных темах. Однако, поскольку система шаблонов блоков отличается, теперь они должны создать два шаблона верхнего уровня, single.html (post) и 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 темы и перезаписать вещи. Простой хук-фильтр сделает это безболезненным.