WordPress стрімко змінюється. Змінюються концепції тем, змінюється Gutenberg. Що з цього вийде до кінця незрозуміло. Але стежити за процесом досить захоплююче. У цій статті розглянемо що нового сталося c темами в WordPress за останній рік і до чого нам, можливо, варто готуватися.

До і після 5.0

Кінцевою метою WordPress (і Gutenberg) є дати можливість користувачам кастомізувати кожен аспект їх сайту через систему блоків. В даний час система блоків дозволяє редагувати лише контент постів, але як тільки ми наблизимося до full-site редагування, кожна частина сторінки стане блоком. А, значить, доступною для змін. Уявіть собі світ, в якому користувачі зможуть розміщувати блоки в футер або хедер.

Одним з кроків на цьому етапі стало впровадження Gutenberg. І для багатьох це стало справжнім болем. Але, як показує практика, людина звикає до всього, навіть до Gutenberg'у.

А якщо подивитися на це з позитивної сторони. Ось кілька переваг Gutenberg'a:

1. Буде однозначним плюсом, якщо ви почали використовувати WordPress починаючи з версії 5.0 і просто не бачили нічого іншого
2. З Gutenberg не потрібно десятки шаблонів сторінок. Досить oдного або декількох, а різні варіації дизайну можна створювати блоками.
3. Блоки універсальні для різних типів даних. Це означає, що один і той же блок можна використовувати як в постах так і сторінках.
4. Розробники можуть писати свої блоки. Вже сьогодні є десятки плагінів, які додають в редактор найрізноманітніші блоки. Від простих роздільників, до складних галерей і форм зворотного зв'язку.

Ну і давайте подивимося правді в очі: класичний редактор відмінно працює з короткими постами, парочкою заголовків і параграфів. Але як тільки потрібно створити пост, де буде кілька колонок без шорткодів, не відкриваючи при цьому табу Text, починається суцільна біль.

Блоки не тільки в контенті

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

Щоб досягти повного full-site редагування, кожен шматочок динамічних даних на сайті повинен стати блоком. Наприклад, блок навігації по сайту. І користувач повинен мати можливість засунути його куди завгодно. Навіть в хедер, якщо йому так хочеться.

Підготовча робота для забезпечення такого майбутнього ведеться вже більше року. Правда, із запланованих 9 проектів в 2019 було на 100% реалізовано і запущено тільки 2. Що в контексті таких глобальних змін навіть непогано. З нововведень минулого року: всі існуючі віджети були перенести в блоки і Site Health check плагін був доданий в ядро, щоб полегшити дебаггінг.

2020 має стати роком full-site редагування. Стежити (і участвувати) за процесом можна в Slack-каналі core-editor. І, звичайно, буде продовжена робота над Директорією блоків.

Все це породжує у нас цілком закономірне питання: "Якщо користувачі зможуть рухати блоки довільно туди-сюди, то як в це все вбудується власне в теми? І якщо сайт буде повністю складатися з блоків чи потрібні теми взагалі?

Зараз для порівняння, в найпопулярнішій темі з ThemeForest напхано все підряд: і стилі, і шаблони сторінок, і купа опцій.

Кожному по шаблону

Кінцевої відповіді на це питання поки немає. В цілому запропоновані структури не сильно відрізняються від вже існуючих тем в WordPress. Найбільша відмінність в тому, що темплейти шаблонів будуть тепер "блоками темплейтів" і "блоками частин темплейтів". І ці темплейти будуть не в РНР файлах, а в HTML.

Виглядати це все буде приблизно ось так:

theme
 | __ style.css | _ _ Functions.php
 | __ block-templates | _ _ Index.html
     | __ single.html | _ _ Archive.html
     | __ ... | _ _ Block-template-parts
     | __ header.html | _ _ Footer.html
     | __ sidebar.html | _ _ ...

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

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

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

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

Фінальне рішення про те, як шаблони будуть декларувати темплейти, ще не прийнято. На даний момент в якості драфта використовується досить-таки давнє рішення і виглядає воно так:

$ single = array (
   array ( 'core / site-title' , array ()),
   array ( 'core / image' , array (
     'sizeSlug' => 'large' ,)),
   array ( 'core / group' , array (), array (
     array ( 'core / post-title' , array ()),
     array ( 'core / post-content' , array ()),)),
   array ( 'core / heading' ,array(
     'Content' => 'Footer' ,)),);

Самі темплейти визначаються як список елементів блоку. І такі блоки можуть містити зумовлені атрибути, плейсхолдери, контент і т.д. Наприклад, ось так можна створити InnerBlock область, куди увійдуть дві колонки: одна з картинкою і одна з абзацом тексту:

const TEMPLATE = [[ 'core / columns' , {}, [[ 'core / column' , {}, [[ 'core / image' ],]], [ 'core / column' , {}, [[ ' core / paragraph ' , { placeholder : ' Enter side content ... ' }],]],]]]; ... <InnerBlocks template = {TEMPLATE} />

Tеми все-таки залишаються темами

Якщо пробратися через все нетрі WordPress, то за фактом теми завжди були HTML і CSS. А сам РНР при цьому просто міксував виклик РНР функцій (наприклад, template tags) з якою-небудь структурованою HTML розміткою. І якщо подивитися на більшість шаблонів, які знаходяться в офіційній WordPress директорії, то можна легко помітити, що основна розмітка залишилася практично тією ж старою, доброю і звичною.

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

Наприклад, якщо нам потрібен новий компонент, то на РНР ми робимо якийсь "Block Areas", а потім до нього створюємо всі області, які потрібні користувачеві (сайдбар, хедер, футер та ін.) І потім присвоюємо їх до місця в шаблоні.

Тоді в functions.php буде щось типу:

function  wp_custom_blockarea () {Register_block_area ( 'header-area' , __ ( 'Header Area' )); register_block_area ( 'footer-area' , __ ( 'Footer Area' )); register_block_area ( 'sidebar-area' , __ ( 'Sidebar Area' )); } Add_action ( 'init' , 'wpb_custom_new_menu' );

А в header.php, footer.php або sidebar.php буде щось на зразок:

<? php wp_block_area ( 'header-area' ); ?>

Кінцеві користувачі зможуть створювати шаблони самостійно

Шок-контент: кожен WordPress користувач, який вміє щось робити (наприклад, WordPress адмін), зможе отримати доступ до цих темплейтів через свою адмінську частину, редагувати їх і навіть експортувати темплейт як шаблон.

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

Замість підсумку

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

По матеріалам Dmitry Mayorov