✅ WEB і WordPress новини, теми, плагіни. Тут ми ділимося порадами і кращими рішеннями для сайтів.

Створюйте та вибирайте власні кінцеві точки REST у блоках Гутенберга

9

У цій публікації я спробую створити огляд того, як створювати власні кінцеві точки REST API і виконувати запити для них у спеціальному блоці Gutenberg. Тобто робити запити за допомогою fetchметодів інформації, недоступної в зареєстрованих сховищах даних WordPress.

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

WordPress REST API

Якщо ви ще не знали; WordPress REST API — це інтерфейс JSON для надсилання та отримання даних із вашого сайту WordPress. Його можна використовувати зовнішньо або внутрішньо. З редактором Gutenberg і переходом на Javascript використання REST API безперечно збільшилося. WordPress REST API має цілий набір кінцевих точок, які ми можемо використовувати. Дивіться повну довідку про всі кінцеві точки REST API тут. Ви знайдете, наприклад, кінцеві точки для публікацій та більшості іншого внутрішнього вмісту – як для читання, так і для оновлення. Розробники тем або плагінів можуть зареєструвати власні кінцеві точки.

Ваш сайт WordPress має кореневу URL-адресу REST API, яка за умовчанням розташована за адресою <your domain>/wp-json. Наприклад, локальний WordPress із URL-адресою http://localhost/wordpress/може отримати доступ до REST API за адресою http://localhost/wordpress/wp-json. Звідти нам потрібно додати кінцеві точки. Звертаючись до наведеного вище посилання на кінцеві точки, ми можемо отримати список останніх публікацій у кінцевій точці /wp/v2/posts. Це означає, що якщо ви зайдете http://localhost/wordpress/wp-json/wp/v2/postsу своєму браузері, ви отримаєте відповідь у форматі JSON із останніми публікаціями на вашому сайті WordPress.

Примітка щодо просторів імен доречна. URL-адреса REST API починається з простору імен (" wp/v2" – це простір імен WordPress, як показано у прикладі URL-адрес вище). Простори імен — це концепція, яка дозволяє уникнути зіткнень у ядрі WordPress, темах і плагінах, які додають кінцеві точки з однаковими іменами. Створіть свій власний унікальний простір імен – як правило, це слаг-форма назви вашої теми чи плагіна. Після слага загальне правило додає номер версії, зазвичай починаючи з v1. Як приклад, слаг моєї теми — «awhitepixel», тому, якби я мав створювати власні кінцеві точки в своїй темі, я б використав простір імен «awhitepixel/v1». За допомогою цього простору імен я міг би зареєструвати кінцеву точку " posts", і це не спричинило б проблем, навіть якщо воно ідентичне назві кінцевої точки WordPress.

Робота з REST API у WordPress — велика тема з великою кількістю корисної інформації. У цій публікації я зосереджусь на зручності використання в редакторі Gutenberg і тому, як отримати їх у Javascript.

Що ми зробимо, і що нам потрібно

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

Коли ми створюємо спеціальну кінцеву точку, ми повністю контролюємо її повернення. Ми можемо виконувати будь-які операції та запити в WordPress/PHP і передавати їх у форматі JSON. І в нашому блоці Гутенберга ми зможемо отримати цей результат і робити з ним те, що хочемо, у функції блоку edit. Зазвичай ви використовуєте дані, щоб надати кінцевому користувачеві вибір або інформацію в редакторі блоків, але ви також можете зберігати інформацію з них у своєму блоці для подальшого використання. Ви також можете створити власні сховища для цих даних, але я не буду вдаватися в те, як це зробити.

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

Створення кінцевої точки REST API

Реєстрація спеціальної кінцевої точки REST API виконується в PHP. Ви повинні додати цей код у свою тему functions.phpабо активний код плагіна. Підключіть функцію до дії rest_api_initта запустіть функцію [register_rest_route](https://developer.wordpress.org/reference/functions/register_rest_route/)()для кожної кінцевої точки, яку ви хочете зареєструвати.

Надайте свій простір імен як перший параметр, ваш маршрут кінцевої точки як другий і масив налаштувань як третій параметр для register_rest_route(). Четвертий параметр визначає, чи бажаєте ви перевизначити існуючий маршрут; не те, на що ми тут розглянемо. У масиві для третього параметра ви повинні як мінімум встановити властивість «callback» на функцію, яка відповідає за повернення даних кінцевої точки. Налаштування " method" також є поширеним, наприклад, встановлення кінцевої точки на " GET", " POST", " PUT" тощо.

Почнемо з реєстрації простої кінцевої точки;

Простір імен моєї теми — «awhitepixel/v1», і я реєструю кінцеву точку «mydata» у цьому просторі імен. Це означає, що я можу отримати доступ до свого спеціального REST API за адресою http://localhost/wordpress/wp-json/awhitepixel/v1/mydata.

Під час реєстрації (або зміни) маршрутів REST API вам потрібно буде очистити свої постійні посилання, щоб вони працювали. Ви можете зробити це, відвідавши Налаштування > Постійні посилання та просто натиснувши Зберегти.

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

По-перше, ви повинні завжди повертати щось із зворотного виклику кінцевої точки. Будь-яке повернення буде автоматично конвертовано в JSON WordPress. Це означає, що ви можете повернути практично будь-яку форму даних у вашій функції; рядок, нуль, масив або [WP_Error](https://developer.wordpress.org/reference/classes/wp_error/)примірник. Ви також можете вибрати повернення [WP_REST_Response](https://developer.wordpress.org/reference/classes/wp_rest_response/)об’єкта для більшого контролю, наприклад, коду статусу або інформації заголовка. Я рекомендую обернути повернення у функцію [rest_ensure_response](https://developer.wordpress.org/reference/functions/rest_ensure_response/)(), щоб переконатися, що ваша відповідь є дійсною відповіддю REST.

Давайте визначимо нашу функцію зворотного виклику та повернемо простий рядок як початок;

function awhitepixel_rest_route_mydata($data) { $response = 'Hello there!'; return rest_ensure_response($response); }

За допомогою наведеного вище коду (і очищених постійних посилань) тепер я можу перейти до URL-адреси http://localhost/wordpress/wp-json/awhitepixel/v1/mydata.

Створюйте та вибирайте власні кінцеві точки REST у блоках Гутенберга

З цього моменту ми можемо додати будь-який код у нашу функцію зворотного виклику, щоб створити правильні дані для повернення. Ви можете запитувати вміст WordPress за допомогою, наприклад [WP_Query](https://developer.wordpress.org/reference/classes/wp_query/), робити запити в базі даних або запитувати зовнішні дані. Ця частина залежить від вас.

Тепер перейдемо до протилежної сторони; як робити запити.

Створення запитів REST API в Javascript

Виконання запиту REST зазвичай виконується за допомогою [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)Javascript. WordPress надає власну оболонку fetch, яка спрощує запити WordPress REST API; [wp.apiFetch](https://developer.wordpress.org/block-editor/packages/packages-api-fetch/). Це те, що я буду використовувати у своєму спеціальному блоці Гутенберга. Майте на увазі, що fetchзапити повертають «обіцянку», тому нам потрібно зв’язати a .then(), щоб обробити фактичне повернення запиту. Базове використання приблизно таке;

apiFetchдозволяє нам надати pathвластивість замість створення повної URL-адреси. Все, що нам потрібно надати, це простір імен і кінцева точка, і ми apiFetchдодамо це до кореневої URL-адреси REST API WordPress. Усередині .then()функції ми маємо доступ до даних, які вже перетворені в JSON. Тут ви повинні щось зробити з даними. Зазвичай ви зберігаєте повернуті дані, наприклад, у стані компонента.

Нижче наведено приклад спеціального editкомпонента блоку Гутенберга. Він базується на класі, щоб використовувати stateдля зберігання даних, повернутих із запиту REST API. Це також дозволяє нам запускати запит під componentDidMount()час його першого монтування (дивіться документацію React про методи життєвого циклу ). Все це надає простий приклад, щоб ви могли зрозуміти основну концепцію; не як рецепт, щоб зробити це саме так. Ви можете розглянути можливість використання хуків React і функціональних компонентів або замість цього створити компонент вищого порядку .

Наведений вище приклад є складеним на основі класу, який надається функції блоку editв registerBlockType(). Він встановлює об’єкт стану масиву для зберігання даних (очевидно, це залежить від даних, які ви повертаєте), і логічне значення статусу, щоб знати, коли асинхронний запит повернувся. Після монтування компонента (відображеного вперше) він запускає функцію для виконання apiFetchзапиту. Ми встановили шлях до кінцевої точки, яку ми зареєстрували в PHP вище. Метод за замовчуванням GET, тому нам не потрібно вказувати це в apiFetch. А всередині .then()функції, коли запит готовий, ми оновлюємо стан компонента за допомогою повернутих даних.

Очевидно, що функція візуалізації вашого блоку зробить більше з самими повернутими даними. Можливо, ви захочете надати дані користувачеві якимось чином представивши список для вибору. Все залежить від того, які це дані та для чого ви хочете їх використовувати.

Передача аргументів до кінцевої точки

У деяких випадках нам потрібно передати деякі аргументи кінцевій точці. Зазвичай використовується передача ідентифікатора після кінцевої точки; наприклад http://localhost/wordpress/wp-json/wp/v2/posts/14, поверне ідентифікатор публікації 14.

Це досить просто і робиться шляхом додавання шаблону пошуку регулярного виразу до кінцевої точки під час її реєстрації. Для побудови складних шаблонів потрібні певні знання регулярних виразів, але нижче наведено приклад, який відповідає числу та присвоює йому ім’я «id». Назви збігів дають нам засоби доступу до змінної в нашій функції зворотного виклику. Дозвольте мені показати вам, що я маю на увазі.

Давайте зареєструємо новий маршрут кінцевої точки. Ми використовуємо ту саму кінцеву точку, що й раніше (‘ awhitepixel/v1/mydata‘), але для цього маршруту ми додаємо збіг регулярного виразу для числа в кінці.

Шаблон регулярного виразу (?P<id>[d]+)здається загадковим, але буде досить зрозумілим, якщо ви зрозумієте регулярні вирази. Частина [d]+збігається з будь-яким числом (0-9) 1 або більше разів. Частини та призначені (?P<id>для )відповідності іменованій групі. Назва групи в цьому випадку id, але ви можете назвати групу(и) як завгодно.

Ви можете скерувати цю кінцеву точку до окремої функції зворотного виклику, але я вирішив використовувати ту саму функцію для обробки обох /mydataзапитів /mydata/<ID>. Це означає, що я можу у своїй функції зворотного виклику:

function awhitepixel_rest_route_mydata($data) { if ($data['id']) { $response = 'Create return for ID: '. $data['id']; } else { $response = 'Create general return (no ID provided)'; } return rest_ensure_response($response); }

Пам’ятайте, що параметр функції зворотного виклику містить повернуті аргументи. Оскільки я назвав свою відповідну групу «id», відповідне значення буде доступним у $data['id']. І, нарешті, оскільки я використовую ту саму функцію для обробки запитів із ідентифікатором і без нього, я можу легко перемикатися між двома різними поверненнями.

Завдяки цьому (і оновленим постійним посиланням) я отримаю такі відповіді для своїх користувацьких кінцевих точок:

Створюйте та вибирайте власні кінцеві точки REST у блоках ГутенбергаСтворюйте та вибирайте власні кінцеві точки REST у блоках Гутенберга

Джерело запису: awhitepixel.com

Цей веб -сайт використовує файли cookie, щоб покращити ваш досвід. Ми припустимо, що з цим все гаразд, але ви можете відмовитися, якщо захочете. Прийняти Читати далі