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

У WordPress 5.8 введена система вибору варіантів тем, що дозволяє налаштовувати параметри блоку, стилі, шаблони і т.д. Це робиться за допомогою нового файлу theme.json, який розробники можуть розмістити в корені своїх тематичних папок. Опубліковано Енн Маккарті, керівника програми FSE Outreach Опитування , щоб отримати відгук розробника щодо цієї функції.

«Оскільки цей механізм є першим кроком до спільної системи стилів у WordPress, важливо почути думку кожного, хто в даний час використовує theme.json. Ми повинні знати, як люди працюють з цим інструментом, що ще може бути включено в ядро в майбутньому», – йдеться в анонсі Енн.

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

Я багато працював з цією системою протягом останніх декількох місяців, тому мені було що сказати. І взагалі, мені подобається брати участь в опитуваннях, пов’язаних з WordPress. У той же час, я зміг поділитися своїми думками про поточний стан теми.

Нижче наведені мої відповіді на питання анкети.

Примітка: Пост спрямований на розробників. Звичайним читачам може не надається необхідність розуміння деяких аспектів розвитку теми. Пост розповідає від імені Джастіна Тедлока.

Досвід розробника

Перше питання досить просте. Який ваш досвід роботи з темами блокування та theme.json. Є чотири відповіді (і “інший” варіант):

  • Я створив і побіг блокувати теми.
  • Я експериментував з розробкою тем блоків.
  • Я використовував theme.json в класичних темах.
  • Я використовував теми блоків, але не натрапив на їх розвиток.

Я вибрав перший варіант, тому що раніше я створив блок теми для сім’ї та друзів. Це були прості особисті сайти, які я підтримую безкоштовно – в цілому, я б вже почав стягувати за це плату. Я також працюю над темою, яку я хочу опублікувати в майбутньому.

Початок роботи з theme.json і блокування тем

Друге питання пов’пов’я з тим, як ви почали працювати з темами блоків та theme.json. Тут ви можете обрати елементи: вилку існуючої теми, використання порожньої теми Пуста тема або написання теми з нуля.

Знову ж таки, я експериментував по всій дошці, так що я не пам’ятаю, де я почав. Більшу частину часу я проводив на вилку теми, і востаннє це було в 2019 році.

Я планую випустити його безкоштовно десь у майбутньому. В основному, мої очікування такі:

  • Остаточне вивчення навігаційного блоку.
  • Порушення пост автор блоку на менші блоки.
  • Надійний набір блоків, пов’язаних з коментарями.
  • Опублікувати вибране зображення з параметром вибору розміру зображення.

Якби ці питання були вирішені, я б випустити бета-версію моєї теми сьогодні.

Шаблони та розділи шаблонів

Під час опитування було запропоновано, які шаблони та розділи шаблонів ви завжди додаєте до тем блоків.

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

Я не пам’ятаю, коли я востаннє створював тему на основі PHP з більш ніж одним шаблоном верхнього рівня: index.php. Динамічні розділи завжди були всередині шаблонів. За допомогою PHP ви можете легко встановити змінну або використовувати виклик функції для контекстного завантаження розділів шаблонів, необхідних для сторінки, яку зараз переглядає користувач.

Система шаблонів блоків не працює таким чином. Виявляється, розробникам варто відмовитися від принципу «Не повторюй себе» (DRY).

Наприклад, якщо дизайнер раніше хотів вивести різні частини заголовка для публікацій та сторінок, йому потрібно було лише створити заголовок.php або шаблон заголовка.php у традиційних темах. Але оскільки система шаблонів блоків відрізняється, дизайнерам тепер потрібно створити два шаблони верхнього рівня, один.html та сторінку.html для досягнення однієї й тієї ж мети.

І це погано, тому що розробникам тем потрібно дублювати весь код в кожному з шаблонів верхнього рівня. Не можна контекстно завантажувати різні розділи шаблонів.

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

Я також відповів на другу частину питання і перерахував naib.Я використовую розділи шаблонів, які я використовую часто (розбиті за ієрархією):

  • заголовок
  • вміст
  • – Петля
  • – Бічна панель
  • Нижній колонтитул

Визначення кольору

У наступному розділі програма запитає вас про те, як автори теми визначають слимаки палітри кольорів у theme.json. Ви не повірите, але назва квітів “гаряча точка» у світі тем останніх років. Розробники зазвичай погоджуються з кольорами фону імені та переднього плану.

У 2018 році Мортен Ренд-Гендріксен відкрив квиток щодо стандартизації схеми найменування кольорів. Це була не перша дискусія і не остання. Проблемою, піднятою в квитку, були постановки кольорів в системі (особливості налаштування колірних палітр в темах). Як тільки користувач вибирає попередньо встановлений колір, службовий слимак відразу ж прописаний в коді. Досить переключитися на іншу тему з іншими компонентами – і старі кольори зникнуть. Автоматичний перехід до кольорів нової теми не відбудеться.

Я використовую семантичні імена, які дещо нагадують Система прийнята в Tailwind CSS-рамки. Замість червоного носія (описове ім’я) я використовую первинний-500 (семантичне ім’я). Семантичний підхід дозволяє авторам тем визначати набір кольорів, які оновлюватимуться кожного разу, коли користувач перемикає тему.

Природно, є й інші підходи. Навіть розробники, які віддають перевагу семантичному імені, не завжди згодні з тією ж системою. Я описав свій підхід більше в деталях в останньому квитку GitHub. У мене також є тема.json Ґіст (Ґі для тих, хто хоче спробувати все це.

Інші параметри JSON

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

Одне з параметрів, для яких наразі немає WordPress — це глобальний відступ (інтервал). Більшість авторів тем зазвичай використовують однакове значення для всіх вертикальних полів (відступи між блоками та елементами). Часто встановлюються базові вертикальні та горизонтальні заповнення.

Я не впевнений, якщо мені потрібна така пресет, так як я не знаю, як вона буде застосовуватися в 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 для зв’язування конфігурацій разом буде більш природним кроком для розробників традиційних тем. Це буде демонстрація доброї волі з боку розробників ядра / Гутенберга, адже в цьому випадку авторам тем буде набагато простіше освоїти функціонал FSE за допомогою вже знайомої мови програмування.

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

джерело: wptavern.com

Прокоментувати

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *