Поки що ми відтворювали вихідні дані блоку в Javascript. Однак з динамічним вмістом, таким як останні публікації або відображення публікації, нам потрібно відобразити вивід блоку в PHP. У цій публікації ми дізнаємося, як і чому.
Чому нам потрібно по-різному обробляти динамічні блоки?
Деякі приклади очевидні; блок, який відображає останні дописи в категорії, є динамічним, оскільки дописи змінюватимуться з часом. Ви не вибираєте пости в блоці; натомість ви, ймовірно, матимете налаштування для вибору категорії, яку інформацію відображати для кожної публікації, кількості публікацій, кількості стовпців тощо. Кожного разу, коли WordPress завантажує публікацію з цим блоком, йому потрібно запитувати WordPress про найновіші публікації. Перегляд тієї самої публікації через місяць може дати інші результати, навіть якщо сама публікація з блокуванням не була оновлена.
Але необхідність динамічних блоків іноді не така очевидна. Ви можете уявити, що блок рекомендованих дописів, де ви вибираєте одну конкретну публікацію для її відображення, не обов’язково є динамічним. Але це могло бути – і повинно бути. Пам’ятайте, що вибрана публікація може будь-коли оновити назву, уривок або представлене зображення – і це має бути відображено в блоках, які містять цю публікацію.
Щоб створити нединамічний блок для показу окремого допису, вам потрібно буде зберегти ідентифікатор допису, його URL-адресу, URL-адресу обраного зображення, рядок уривка або будь-що, що вам потрібно для попереднього перегляду допису, в атрибутах блоку. І тут криється проблема. Якщо ви оновите пропоноване зображення вибраного допису, допис із пропонованим блоком не оновлюватиме автоматично свої атрибути. Воно залишиться збереженим із URL-адресою старого представленого зображення. Лише коли ви відредагуєте допис із блоком і переконаєтеся, що він повторно зберігає атрибути з оновленою інформацією, у блоці відображатиметься правильна оновлена інформація.
Тож щоразу, коли ми маємо справу з динамічним вмістом – публікаціями, категоріями чи будь-чим, що може змінитися з часом – ми маємо справу з динамічними блоками. А для динамічних блоків нам потрібно використовувати PHP – код на стороні сервера – для візуалізації нашого блоку, щоб гарантувати, що він отримуватиме оновлену інформацію щоразу під час рендерингу.
Змінений характер динамічних блоків у редакторі
Коли ви почнете розробляти динамічні блоки, характер вашого блоку в редакторі зміниться. Функція вашого блоку також editчасто має бути динамічною. Наприклад, для блоку рекомендованих дописів вам потрібно буде отримати дописи на вибір, або для блоку останніх новин вам потрібно буде отримати список категорій для вибору користувача.
Цілком можливо запитувати інформацію з WordPress із редактора, виконуючи запити AJAX – або використовуючи пакети та компоненти, або виконуючи їх вручну за допомогою WordPress REST API. Незалежно від методу, який ви використовуєте, ваш блок повинен обробляти асинхронний потік введення – часовий проміжок під час очікування відповіді.
Існує кілька методів і шаблонів для створення динамічного блоку для Gutenberg. Найчастіше ви використовуєте шаблон React, який називається компонентами вищого порядку, для якого WordPress надає багато функцій і компонентів.
У наступній частині підручника ми розглянемо, як отримати повідомлення та як отримати категорії в нашому блоці. Наразі нам потрібно навчитися, як змусити PHP рендерити наш блок.
Готуємо наш блок для рендерингу PHP
Основна частина, яку нам потрібно зробити в Javascript, — це змусити функцію блоку saveповертати null. Ви можете залишити вихідний вихід, але якщо ми накажемо WordPress використовувати PHP для відтворення блоку, це буде проігноровано. Щоб зрозуміти для себе та інших, що вихід блоку не обробляється в Javascript, ми змінимо цю saveфункцію.
Не забувайте, що зміна функції збереження зруйнує всі існуючі блоки. Повторно додайте блок. Блок повинен працювати як і раніше; з налаштуваннями та оновленням атрибутів. Тепер він просто не буде виводити нічого у інтерфейсі. Там буде блок коментарів, який зберігає всі атрибути в JSON, але видимий HTML не відображається.
Однак; якщо будь-який із ваших атрибутів використовує sourceвластивість, вам потрібно це змінити. Це не підтримується блоками, які відображаються за допомогою PHP, оскільки вони аналізуються безпосередньо з виводу збереження, до якого ми тепер повертаємося null. Джерело використовуємо на другому RichTextв нашому блоці – для абзацу. На цьому етапі редактор взагалі не збереже те, що ви тут додали RichText.
Отже, якщо ви все ще використовуєте атрибут sourceon myRichText, нам потрібно видалити властивості sourceand selector, щоб гарантувати, що атрибути зберігатимуться, а не аналізуватимуться з saveфункції:
attributes: {
...
myRichText: {
type: 'string',
},
...Після цього наш блок готовий до відтворення в PHP. Ми можемо залишити файли Javascript (не забудьте створити його), а решта буде зроблено в PHP.
Відтворення блоків у PHP
Щоб наказати WordPress відтворювати вихідні дані блоку в PHP, ми додаємо новий аргумент до функції register_block_type(). Нам потрібно додати ключ render_callbackдо масиву зі значенням функції, яку він має виконувати.
Функція візуалізації PHP
Давайте визначимо функцію awp_myfirstblock_renderнижче functions.php(або там, де ви розмістили свій PHP-код). Наша функція отримає два параметри; ми подзвонимо їм $attrі $content.
function awp_myfirstblock_render($attr, $content) {
// return the block's output here
}Параметр $attrбуде представляти собою асоціативний масив з усіма збереженими атрибутами. Другий параметр, $content, призначений для блоків усередині нашого блоку. Це актуально лише для блоків, які підтримують вкладені блоки, наприклад стовпці або обкладинка.
Функція ніколи не повинна echoнічого виводити. Необхідно повернути весь вихід, тому вам потрібно створити рядок і повернути його в кінці.
Про атрибути важливо пам’ятати, що лише збережені атрибути відображатимуться в першому параметрі функції. Якщо атрибут ніколи фактично не змінювався та не зберігався, тобто просто покладався на його default, атрибут взагалі не буде включено до нашої функції PHP.
Ви повинні вирішувати цю проблему або завжди перевіряючи if (isset($attr['...'])), або кращим способом: визначаючи атрибути в нашому register_block_type()виклику. Ми можемо надати інший ключ, attributesі встановити його значення як масив з усіма атрибутами, які ми хочемо отримати з нашого блоку. Структура має бути ідентичною тій, яку ви визначили в Javascript, але замість об’єкта Javascript вона потрібна в масиві PHP. Це може бути трохи громіздким для перевизначення тих самих атрибутів, але з розумним редактором коду це має бути досить швидко копіювати+вставляти та редагувати багато рядків у PHP.
Додаємо атрибути для нашої функції візуалізації
Давайте додамо новий attributesелемент register_block_type()і вставимо ті самі атрибути, які ми визначили в нашому файлі Javascript:
Майте на увазі, що якщо ви визначаєте defaultдля всіх атрибутів, $attrпараметр вашої функції має завжди містити всі атрибути. Наприклад, наведений textAlignmentвище атрибут існуватиме, лише $attrякщо його було змінено, і вам потрібно буде перевірити isset($attr['textAlignment']).
На жаль, на даний момент є дві речі, якими ви не зможете оволодіти за допомогою PHP block render. Один — classNameпроп, тож вам потрібно самостійно створити клас упаковки (якщо ви цього хочете). Інша supportвластивість для вирівнювання блоків. На даний момент WordPress не підтримує цю властивість у динамічних блоках. Ми не отримаємо значення вибраного вирівнювання блоку, якщо не змінимо його на атрибут і не обробимо його вручну в Javascript.
Що стосується HTML-виводу функції, це повністю залежить від вас!
Запит на візуалізацію PHP із внутрішнього редактора
У редакторі можна запросити рендер PHP нашого блоку. Це корисно, якщо ви хочете мати можливість попередньо переглядати вихідні дані блоку в редакторі. Ми можемо зробити це за допомогою компонента, викликаного ServerSideRenderз wp.editorпакету.
Як реквізит ServerSideRenderвам потрібно визначити всі атрибути, які ви хочете передати. Як мінімум вам потрібно вказати ім’я блоку в prop block, щоб WordPress знав, який метод візуалізації шукати. Це доступно для вас у props.nameфункції edit. Вам також потрібно надати будь-які необхідні атрибути в prop attributes. Якщо ви хочете, ви також можете додати сюди спеціальні змінні поза атрибутами. Просто майте на увазі, що це працюватиме лише для внутрішнього редактора, а не для інтерфейсу.
Ви не можете використовувати ServerSideRenderу функції блоку save. Ваша saveфункція все одно має повернутися null.
Давайте реалізуємо ServerSideRenderв нашому блоці, щоб побачити це на практиці.
Використання ServerSideRender для режиму попереднього перегляду/редагування блоку
Якщо ви дотримувалися попереднього кроку, де ми зробили перемикач режимів попереднього перегляду/редагування для нашого блоку, тепер ми можемо використати ServerSideRenderдля візуалізації попереднього перегляду блоку з PHP, коли ми перемикаємось у режим попереднього перегляду.
Спочатку нам потрібно не забувати деструктурувати ServerSideRenderвгорі:
const { ServerSideRender } = wp.editor;Якщо ви пам’ятаєте з попереднього кроку, ми використовували компоненти Disabledта/або Placeholderдля попереднього перегляду. Проблема з використанням Placeholderполягає в тому, що ми отримуємо небажаний стиль, застосований до нашого результату. Замінимо Placeholderна ServerSideRender. Ви можете залишити Disabledкомпонент, щоб гарантувати, що його вміст не можна буде натиснути чи перетягнути.
У коді для рендерингу блоку, коли атрибут editModefalse, ми робимо:
Тепер наша спеціальна кнопка на панелі інструментів відображатиме вихідні дані з PHP, коли ми переходимо в режим попереднього перегляду. Вихід має бути ідентичним під час перегляду публікації у інтерфейсі. Це гарна звичка, щоб гарантувати, що результат ідентичний як у редакторі, так і в інтерфейсі.
Приклад: динамічний блок, що показує вибрану публікацію
Вихід у вашій функції візуалізації PHP може бути будь-яким, і ви маєте повний доступ до всіх функцій WordPress. Припустимо блок, де ідентифікатор публікації буде збережено в атрибуті. У функції render_callbackPHP ви можете запитати публікацію з ідентифікатора та вивести її інформацію. Має бути досить зрозуміло, як це зробити, але ось короткий приклад.
Примітка: у цьому прикладі ми просто додамо текстове введення до редактора для ручного введення ідентифікатора публікації. Це не дуже інтуїтивно зрозуміле та зручне рішення для вибору публікації, але це те, про що ми дізнаємося на наступному кроці. Тут увага зосереджена на PHP-частині відтворення вибраного допису.
Додамо атрибут selectedPostIdтипу number:
attributes: {
selectedPostId: {
type: 'number'
}
}І десь усередині функції нашого блоку editми додаємо TextControlкомпонент. Він може бути де завгодно – у блоці чи в Інспекторі.
Зауважте, що я приділяю особливу увагу тому, щоб вхідні дані правильно зберігали атрибут як число, перетворюючи його на ціле число за допомогою parseInt(). Незважаючи на те, що ми встановили значення type prop typeдля numberтого, щоб відобразити числове введення, змінене значення все одно інтерпретується як рядок. WordPress не збереже ваш атрибут, якщо він має неправильний формат.
Не забудьте додати новий атрибут до свого ServerSideRenderкомпонента, якщо він у вас є:
Частина PHP
Це мало подбати про частину Javascript. Переходимо до PHP. Спочатку нам потрібно додати новий атрибут selectedPostIdдо attributesмасиву в register_block_type():
Тепер у render_callbackфункції ми можемо отримати доступ до ідентифікатора публікації за допомогою $attr['selectedPostId']. З цим ми можемо виконати простий get_post()і вивести дані публікації; його посилання та назва:
Це дуже простий приклад, призначений як трамплін для написання більш розширеного та спеціального коду.
Тепер, коли ми знаємо, як обробляти рендеринг динамічних блоків, наступним кроком буде навчитися також робити частину редактора більш інтуїтивно зрозумілою. У наступному кроці ми зосередимося на тому, як запитувати публікації в редакторі блоків і надамо користувачеві кращий спосіб вибору публікації.