Давайте визнаємо, що зараз розробка для WordPress є дивною. Незалежно від того, чи ви новачок у WordPress, чи працювали з ним багато років, запровадження функцій «Повносайтове редагування» (FSE), включаючи Редактор блоків (WordPress 5.0) і Редактор сайту (WordPress 5.9), перевернули традиційний спосіб створення тем і плагінів WordPress.
Незважаючи на те, що минуло п’ять років відтоді, як ми вперше познайомилися з редактором блоків, розробляти його важко, оскільки документація або відсутня, або застаріла. Це більше твердження про те, як швидко розвиваються функції FSE Джефф поскаржився в останньому дописі.
Приклад: у 2018 році ан вступна серія про входження в розробку Гутенберга було опубліковано прямо тут, на CSS-tricks. З тих пір часи змінилися, і, хоча цей стиль розвитку все ще працює, це так не рекомендується більше (крім того, create-guten-block проект, на якому він заснований, також більше не підтримується).
У цій статті я маю намір допомогти вам розпочати розробку блоків WordPress відповідно до поточної методології. Отже, так, після публікації все може змінитися. Але я спробую зосередитись на цьому таким чином, щоб, сподіваюся, відобразити суть розробки блоків, тому що, хоча інструменти можуть розвиватися з часом, основні ідеї, ймовірно, залишаться незмінними.
Давайте почнемо з пояснення того, що ми маємо на увазі під такими термінами Блоки. Уся розробка цих функцій, що призвела до WordPress 5.0, мала кодову назву «Гутенберг» — знаєте, винахідник друкарський верстат.
З тих пір «Гутенберг» використовувався для опису всього, що пов’язано з блоками, включно з редактором блоків і редактором сайтів, тому воно стало заплутаним настільки, що деякі люди принижувати ім'я. На довершення всього, є Плагін Гутенберга де експериментальні функції перевіряються на можливе включення. І якщо ви думаєте, що назва всього цього «Редагування повного сайту» вирішить проблему, це також викликає занепокоєння.
Отже, коли ми згадуємо «блоки» в цій статті, ми маємо на увазі компоненти для створення вмісту в редакторі блоків WordPress. Блоки вставляються на сторінку чи допис і забезпечують структуру для певного типу вмісту. WordPress поставляється з кількома «основними» блоками для поширених типів вмісту, як-от абзац, список, зображення, відео та аудіо, назвати декілька.
Окрім цих основних блоків, ми також можемо створювати спеціальні блоки. Це те, про що йдеться у розробці блоків WordPress (існує також фільтрація основних блоків, щоб змінити їхню функціональність, але вам, ймовірно, це поки що не знадобиться).
Що роблять блоки
Перш ніж ми заглибимося у створення блоків, ми повинні спочатку зрозуміти, як блоки працюють всередині. Це точно позбавить нас від розчарування пізніше.
Мені подобається думати про блок досить абстрактно: для мене блок — це сутність із певними властивостями (званими атрибутами), яка представляє певний вміст. Я знаю, що це звучить досить розпливчасто, але залишайтеся зі мною. Блок в основному проявляється двома способами: як графічний інтерфейс у редакторі блоків або як фрагмент даних у базі даних.
Коли ви відкриваєте редактор блоків WordPress і вставляєте блок, скажімо, блок Pullquote, ви отримуєте гарний інтерфейс. Ви можете натиснути на цей інтерфейс і відредагувати цитований текст. Панель налаштувань у правій частині інтерфейсу користувача редактора блоків містить параметри для налаштування тексту та налаштування зовнішнього вигляду блоку.
Коли ви закінчите створювати своє чудове pullquote і натискаєте «Опублікувати», увесь допис буде збережено в базі даних у wp_posts стіл. Це не щось нове завдяки Гутенбергу. Так все працювало завжди — WordPress зберігає вміст публікацій у визначеній таблиці в базі даних. Але що нового, це те представлення блоку Pullquote є частиною вмісту, який зберігається в post_content поле wp_posts таблиці.
Як виглядає це уявлення? Гляньте:
It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.
The Encyclopedia of world peas
Схоже на звичайний HTML, чи не так?! На технічному жаргоні це «серіалізований» блок. Зверніть увагу на дані JSON у коментарі HTML, "textAlign": "right". Це ан атрибут — властивість, пов’язана з блоком.
Припустімо, ви закрили редактор блоків, а через деякий час відкрили його знову. Контент з відповідного post_content поле отримує редактор блоків. Потім редактор аналізує отриманий вміст і скрізь, де він зустрічає це:
...
…воно голосно каже собі:
Добре, мені це здається блоком Pullquote. Хм... у нього також є атрибут... У мене є файл JavaScript, який розповідає мені, як побудувати графічний інтерфейс для блоку Pullquote у редакторі з його атрибутів. Я повинен зробити це зараз, щоб відобразити цей блок у всій його красі.
Як розробник блоків, ваша робота полягає в тому, щоб:
Скажіть WordPress, що ви хочете зареєструвати певний тип блоку, з такими-то деталями.
Надайте файл JavaScript редактору блоків, який допоможе відобразити блок у редакторі, а також «серіалізує» його для збереження в базі даних.
Надайте будь-які додаткові ресурси, необхідні для належної роботи блоку, наприклад стилі та шрифти.
Слід зазначити, що все це перетворення із серіалізованих даних у графічний інтерфейс — і навпаки — відбувається лише в редакторі блоків. На передній частині вміст відображається саме так, як він зберігається. Тому, у певному сенсі, блоки — це химерний спосіб розміщення даних у базі даних.
Сподіваємося, це дає вам певну ясність щодо того, як працює блок.
Початок роботи з розробкою блоків WordPress
Блоки - це просто плагіни
Блоки - це просто плагіни. Ну, технічно, ти може поставте блоки в теми і ви може помістіть кілька блоків у плагін. Але частіше за все, якщо ви хочете створити блок, ви збираєтеся створити плагін. Отже, якщо ви коли-небудь створювали плагін WordPress, то ви вже частково впоралися зі створенням блоку WordPress.
Але давайте на мить припустимо, що ви ніколи не встановлювали плагін WordPress, не кажучи вже про блок. З чого ви взагалі починаєте?
Налаштування блоку
Ми розглянули, що таке блоки. Давайте почнемо налаштовувати речі, щоб створити один.
Переконайтеся, що у вас встановлено Node
Це дасть вам доступ до npm та npx команди, де npm встановлює залежності вашого блоку та допомагає компілювати речі, а npx виконує команди для пакетів, не встановлюючи їх. Якщо ви використовуєте macOS, ви, ймовірно, вже маєте Node і можете ним користуватися nvm для оновлення версій. Якщо ви використовуєте Windows, вам знадобиться завантажити та встановити Node.
Створіть папку проекту
Тепер ви можете зіткнутися з іншими підручниками, які переходять прямо в командний рядок і вказують вам встановити пакет під назвою @wordpress/create-block. Цей пакет чудовий, оскільки він видає повністю сформовану папку проекту з усіма залежностями та інструментами, необхідними для початку розробки.
Я особисто йду цим шляхом, коли налаштовую свої власні блоки, але на мить посміхніться мені, тому що я хочу прорізати впевнені речі, які він вводить, і зосередитися лише на необхідних бітах заради розуміння базового середовища розробки.
Ось файли, які я хотів би назвати конкретно:
readme.txt: Це щось на зразок передньої панелі каталогу плагінів, зазвичай використовується для опису плагіна та надання додаткових відомостей щодо використання та встановлення. Якщо ви подасте свій блок до Каталог плагінів WordPress, цей файл допомагає заповнити сторінку плагіна. Якщо ви плануєте створити репо GitHub для свого блокового плагіна, ви також можете розглянути a README.md файл із тією самою інформацією, щоб він там добре відображався.
package.json: це визначає пакети Node, необхідні для розробки. Ми розкриємо його, коли дійдемо до встановлення. У класичній розробці плагінів WordPress ви, можливо, звикли працювати з Composer і a composer.json натомість файл. Це еквівалент цього.
plugin.php: Це основний файл плагіна, і, так, це класичний PHP! Ми розмістимо сюди заголовок і метадані нашого плагіна та використаємо їх для реєстрації плагіна.
Крім цих файлів, є також src каталог, який повинен містити вихідний код нашого блоку.
Маючи ці файли та src каталог — це все, що вам потрібно для початку. Зверніть увагу на це технічно нам потрібен лише один файл (plugin.php), щоб створити плагін. Решта або надають інформацію, або використовуються для керування середовищем розробки.
Вищезазначене @wordpress/create-block package scaffolds ці файли (і багато іншого) для нас. Ви можете думати про це як про інструмент автоматизації, а не про необхідність. Незважаючи на це, це полегшує роботу, тому ви можете взяти на себе сміливість побудувати з ним блок, виконавши:
npx @wordpress/create-block
Встановити залежності блоків
Припустимо, що у вас готові три файли, згадані в попередньому розділі, настав час встановити залежності. По-перше, нам потрібно вказати залежності, які нам знадобляться. Ми робимо це шляхом редагування package.json. Під час використання @wordpress/create-block утиліти, для нас генерується наступне (додано коментарі; JSON не підтримує коментарі, тому видаліть коментарі, якщо ви копіюєте код):
{
// Defines the name of the project
"name": "block-example",
// Sets the project version number using semantic versioning
"version": "0.1.0",
// A brief description of the project
"description": "Example block scaffolded with Create Block tool.",
// You could replace this with yourself
"author": "The WordPress Contributors",
// Standard licensing information
"license": "GPL-2.0-or-later",
// Defines the main JavaScript file
"main": "build/index.js",
// Everything we need for building and compiling the plugin during development
"scripts": {
"build": "wp-scripts build",
"format": "wp-scripts format",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"packages-update": "wp-scripts packages-update",
"plugin-zip": "wp-scripts plugin-zip",
"start": "wp-scripts start"
},
// Defines which version of the scripts packages are used (24.1.0 at time of writing)
// https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
"devDependencies": {
"@wordpress/scripts": "^24.1.0"
}
}
Команда @wordpress/scripts пакет є основною залежністю тут. Як бачите, це а devDependency це означає, що це допомагає розвитку. Як так? Це викриває wp-scripts двійковий файл, який ми можемо використовувати для компіляції нашого коду, з src в каталог build каталог, серед іншого.
Існує ряд інших пакетів, які WordPress підтримує для різних цілей. Наприклад, @wordpress/components пакет забезпечує кілька збірних UI Компоненти для редактора блоків WordPress, який можна використовувати для створення узгодженого взаємодії з вашим блоком, який відповідає стандартам дизайну WordPress.
Ви насправді ні необхідність щоб інсталювати ці пакунки, навіть якщо ви хочете ними скористатися. Це тому, що ці @wordpress залежності не входять у ваш блоковий код. Натомість будь-який import оператори, що посилаються на код із пакетів утиліт — наприклад @wordpress/components — використовуються для створення файлу «активів» під час компіляції. Крім того, ці оператори імпорту перетворюються на оператори, що відображають імпорт властивості глобального об’єкта. Наприклад, import { __ } from "@wordpress/i18n" перетворюється на мінімізовану версію const __ = window.wp.i18n.__. (window.wp.i18n будучи об'єктом, який гарантовано буде доступним у глобальній області видимості, коли відповідний i18n файл пакета поставлено в чергу).
Під час реєстрації блоку у файлі плагіна файл «assets» неявно використовується, щоб повідомити WordPress про залежності пакетів для блоку. Ці залежності автоматично ставляться в чергу. Про все це подбають за лаштунками, якщо ви використовуєте scripts пакет. З огляду на це, ви все ще можете вибрати локальне встановлення залежностей для завершення коду та інформації про параметри у вашому package.json Файл:
Тепер, коли package.json налаштовано, ми повинні мати можливість встановити всі ці залежності, перейшовши до папки проекту в командному рядку та запустивши npm install.
Початок роботи з розробкою блоків WordPress
Додайте заголовок плагіна
Якщо ви розробляєте класичні плагіни WordPress, то, мабуть, знаєте, що всі плагіни мають блок інформації в основному файлі плагінів, який допомагає WordPress розпізнавати плагін і відображати інформацію про нього на екрані плагінів адміністратора WordPress.
Ось що @wordpress/create-block згенеровано для мене в плагіні під творчою назвою «Hello World»:
<?php
/**
* Plugin Name: Block Example
* Description: Example block scaffolded with Create Block tool.
* Requires at least: 5.9
* Requires PHP: 7.0
* Version: 0.1.0
* Author: The WordPress Contributors
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*
* @package create-block
*/
Це в головному файлі плагіна, який ви можете називати як завгодно. Ви можете назвати це якось загальним index.php or plugin.php, create-block пакет автоматично називає його тим, що ви надаєте як назву проекту під час його встановлення. Оскільки я назвав цей приклад «Приклад блоку», пакет дав нам a block-example.php файл з усім цим матеріалом.
Ви захочете змінити деякі деталі, наприклад зробити себе автором тощо. І не все це необхідно. Якби я робив це з «нуля», то це могло б виглядати приблизно так:
<?php
/**
* Plugin Name: Block Example
* Plugin URI: https://css-tricks.com
* Description: An example plugin for learning WordPress block development.
* Version: 1.0.0
* Author: Arjun Singh
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*/
Ми вже переглянули необхідні файли для нашого блоку. Але якщо ви використовуєте @wordpress/create-block, ви побачите купу інших файлів у папці проекту.
build/: ця папка отримала скомпільовані ресурси під час обробки файлів для використання у виробництві.
node_modules: тут зберігаються всі залежності розробки, які ми встановили під час запуску npm install.
src/: Ця папка містить вихідний код плагіна, який збирається та надсилається до build каталог. Трохи ми розглянемо кожен файл тут.
.editorconfig: містить конфігурації для адаптації вашого редактора коду для узгодженості коду.
.gitignore: це стандартний файл репо, який визначає локальні файли, які слід виключити з відстеження контролю версій. ваш node_modules обов’язково слід включити сюди.
package-lock.json: це автоматично згенерований файл, який містить для відстеження оновлень необхідних пакетів, які ми встановили npm install.
Блокування метаданих
Я хочу покопатися в src каталог з вами, але спочатку зосередиться лише на одному файлі в ньому: block.json. Якщо ви використовували create-block , це вже є для вас; якщо ні, створіть його. WordPress докладає всіх зусиль, щоб зробити це стандартним, канонічним способом реєстрації блоку, надаючи метадані, які забезпечують контекст WordPress для розпізнавання блоку та відтворення його в редакторі блоків.
Насправді є купа різної інформації ми можемо включити сюди, але все, що насправді потрібно, це name та title. Супермінімальна версія може виглядати так:
$schema визначає форматування схеми, що використовується для перевірки вмісту у файлі. Звучить як обов’язкова річ, але вона абсолютно необов’язкова, оскільки дозволяє допоміжним редакторам коду перевіряти синтаксис і надавати інші додаткові можливості, як-от підказки підказок і автозавершення.
apiVersion відноситься до якої версії Блокувати API використовує плагін. Сьогодні версія 2 є останньою.
name обов’язковий унікальний рядок, який допомагає ідентифікувати плагін. Зверніть увагу, що я поставив перед цим префікс css-tricks/ який я використовую як простір імен, щоб уникнути конфліктів з іншими плагінами, які можуть мати таку саму назву. Натомість ви можете використати щось на зразок своїх ініціалів (наприклад, as/block-example).
title інше обов’язкове поле, і воно встановлює ім’я, яке використовується всюди, де відображається плагін.
category групує блок з іншими блоками та відображає їх разом у редакторі блоків. Поточні існуючі категорії включають text, media, design, widgets, theme та embed, і ви навіть можете створити власні категорії.
icon дозволяє вибрати щось із Бібліотека Dashicons щоб візуально представити ваш блок у редакторі блоків. Я використовую format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote), оскільки в цьому прикладі ми створюємо щось на зразок pullquote. Приємно, що ми можемо використовувати наявні піктограми замість того, щоб створювати власні, хоча це, звичайно, можливо.
editorScript де знаходиться основний файл JavaScript, index.js, живе.
Зареєструйте блок
І останнє, перш ніж ми перейдемо до коду, це зареєструвати плагін. Ми просто налаштували всі ці метадані, і нам потрібен спосіб, щоб WordPress міг їх використовувати. Таким чином WordPress знає, де знайти всі ресурси плагіна, щоб їх можна було поставити в чергу для використання в редакторі блоків.
Реєстрація блоку є подвійним процесом. Нам потрібно зареєструвати його як у PHP, так і в JavaScript. Для сторони PHP відкрийте основний файл плагіна (block-example.php у цьому випадку) і додайте наступне відразу після заголовка плагіна:
Це те, що create-block утиліта створена для мене, тому функція названа так, як вона є. Ми можемо використовувати іншу назву. Головне, знову ж таки, полягає в уникненні конфліктів з іншими плагінами, тому гарною ідеєю буде використовувати тут свій простір імен, щоб зробити його максимально унікальним:
Чому ми вказуємо на build каталог, якщо block.json з усіма метаданими блоку src? Це тому, що наш код ще потрібно скомпілювати. The scripts пакет обробляє код із файлів у src і розміщує скомпільовані файли, які використовуються у виробництві, у build каталог, а також копіюванняblock.jsonфайл в процесі.
Гаразд, давайте перейдемо до сторони JavaScript реєстрації блоку. Відкрити src/index.js і переконайтеся, що це виглядає так:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Ми вступаємо в країну React і JSX! Це повідомляє WordPress:
Імпортуйте registerBlockType модуль з @wordpress/blocks пакет.
Імпортувати метадані з block.json.
Імпортуйте Edit та Save компоненти з відповідних файлів. Пізніше ми додамо код до цих файлів.
Зареєструйте блок і використовуйте Edit та Save компоненти для відтворення блоку та збереження його вмісту в базі даних.
Що трапилося з edit та save функції? Одним із нюансів розробки блоків WordPress є розмежування «бек-енду» від «переднього кінця», і ці функції використовуються для відтворення вмісту блоку в тих контекстах, де edit обробляє внутрішній рендеринг і save записує вміст із редактора блоків до бази даних для відтворення вмісту на передній частині сайту.
Швидкий тест
Ми можемо зробити деяку швидку роботу, щоб побачити, як наш блок працює в редакторі блоків і відображається на інтерфейсі. Давайте відкриємо index.js знову та використовуйте edit та save функції для повернення деякого базового вмісту, який ілюструє, як вони працюють:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
const { name } = metadata;
registerBlockType(name, {
edit: () => {
return (
"Hello from the Block Editor"
);
},
save: () => {
return (
"Hello from the front end"
);
}
});
По суті, це скорочена версія того самого коду, який ми мали раніше, тільки ми вказуємо безпосередньо на метадані в block.json щоб отримати назву блоку, і залишив Edit та Save оскільки ми запускаємо функції безпосередньо звідси.
Ми можемо скомпілювати це, запустивши npm run build в командному рядку. Після цього ми маємо доступ до блоку під назвою «Приклад блоку» в редакторі блоків:
Якщо ми опустимо блок у область вмісту, ми отримаємо повідомлення, яке повертаємо з edit функція:
Початок роботи з розробкою блоків WordPress
Якщо ми збережемо та опублікуємо публікацію, ми отримаємо повідомлення, яке ми повертаємо з save функція під час перегляду на передньому кінці:
Початок роботи з розробкою блоків WordPress
Створення блоку
Здається, все підключено! Ми можемо повернутися до того, що ми мали index.js перед тестом тепер, коли ми підтвердили, що все працює:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Зверніть увагу, що edit та save функції прив’язані до двох існуючих файлів у src каталог, що @wordpress/create-block згенерований для нас і включає всі необхідні нам додаткові імпорти в кожному файлі. Що ще важливіше, ці файли встановлюють Edit та Save компоненти, які містять розмітку блоку.
Задня розмітка (src/edit.js)
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Edit() {
return (
{__("Hello from the Block Editor", "block-example")}
);
}
Бачите, що ми там зробили? Ми імпортуємо реквізит з @wordpress/block-editor пакет, який дозволяє нам генерувати класи, які ми можемо використовувати пізніше для стилізації. Ми також імпортуємо __ функція інтернаціоналізації для роботи з перекладами.
Початок роботи з розробкою блоків WordPress
Інтерфейсна розмітка (src/save.js)
Це створює Save і ми будемо використовувати майже те саме, що й src/edit.js з трохи іншим текстом:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Знову ми отримуємо гарний клас, який ми можемо використовувати в нашому CSS:
Початок роботи з розробкою блоків WordPress
Стайлінгові блоки
Ми щойно розглянули, як використовувати властивості блоку для створення класів. Ви читаєте цю статтю на сайті, присвяченому CSS, тож я відчуваю, що щось пропустив би, якби ми конкретно не розглянули, як писати стилі блоків.
Розрізнення стилів передньої та задньої частини
Якщо ви поглянете на block.json в src у каталозі ви знайдете два поля, пов’язані зі стилями:
editorStyle забезпечує шлях до стилів, застосованих до серверної частини.
style це шлях для спільних стилів, які застосовуються як до передньої, так і до задньої частини.
У Кева Квірка є докладна стаття це показує його підхід до того, як зробити внутрішній редактор схожим на зовнішній інтерфейс користувача.
Нагадаємо, що @wordpress/scripts пакет копіює block.json файл, коли він обробляє код у /src каталог і розміщує зібрані ресурси в /build каталог. Це build/block.json файл, який використовується для реєстрації блоку. Це означає будь-який шлях, який ми пропонуємо src/block.json слід писати відносно build/block.json.
Використання Sass
Ми могли б додати пару файлів CSS у build каталог, посилання на шляхи в src/block.json, запустіть збірку та зупиніть її. Але це не використовує повну силу @wordpress/scripts процес компіляції, який може компілювати Sass у CSS. Замість цього ми розміщуємо наші файли стилів у src та імпортуйте їх у JavaScript.
Роблячи це, ми повинні пам’ятати про те, як @wordpress/scripts стилі процесів:
Файл з назвою style.css or style.scss or style.sass, імпортований у код JavaScript, компілюється в style-index.css.
Усі інші файли стилів скомпільовано та об’єднано index.css.
Команда @wordpress/scripts використання пакетів веб-пакет для комплектації і @wordpress/scripts використовує Плагін PostCSS для роботи над стилями обробки. PostCSS можна розширити додатковими плагінами. The scripts пакет використовує пакети для Sass, SCSS і Autoprefixer, усі з яких доступні для використання без встановлення додаткових пакетів.
Фактично, коли ви обертаєте свій початковий блок за допомогою @wordpress/create-block, ви отримаєте хорошу перевагу з файлами SCSS, які можна використовувати, щоб почати роботу:
editor.scss містить усі стилі, які застосовуються до внутрішнього редактора.
style.scss містить усі стилі, спільні для передньої та задньої частини.
Давайте тепер побачимо цей підхід у дії, написавши невеликий Sass, який ми скомпілюємо в CSS для нашого блоку. Незважаючи на те, що приклади не будуть дуже нахабними, я все одно записую їх у файли SCSS, щоб продемонструвати процес компіляції.
передній та внутрішні стилі
Гаразд, давайте почнемо зі стилів, які застосовуються як до передньої, так і до задньої частини. По-перше, нам потрібно створити src/style.scss (це вже є, якщо ви використовуєте @wordpress/create-block) і переконайтеся, що ми імпортуємо його, що ми можемо зробити в index.js:
import "./style.scss";
Відкривати src/style.scss і скиньте туди кілька базових стилів, використовуючи клас, який був згенерований для нас із реквізитів блоку:
На цьому поки все! Коли ми запускаємо збірку, це компілюється в build/style.css і на нього посилається як редактор блоків, так і інтерфейс.
Внутрішні стилі
Можливо, вам знадобиться написати стилі, специфічні для редактора блоків. Для цього створіть src/editor.scss (знову, @wordpress/create-block робить це за вас) і додайте туди кілька стилів:
Потім імпортуйте його edit.js, який є файлом, який містить наш Edit компонент (ми можемо імпортувати його куди завгодно, але оскільки ці стилі призначені для редактора, логічніше імпортувати компонент тут):
import "./editor.scss";
Тепер, коли ми біжимо npm run build, стилі застосовуються до блоку в обох контекстах:
Початок роботи з розробкою блоків WordPressПочаток роботи з розробкою блоків WordPress
Посилання на стилі в block.json
Ми імпортували файли стилів у edit.js та index.js, але пам’ятайте, що крок компіляції генерує для нас два файли CSS у build каталог: index.css та style-index.css відповідно. Нам потрібно посилатися на ці згенеровані файли в метаданих блоку.
прогін npm run build знову встановіть і активуйте плагін на своєму сайті WordPress, і ви готові ним користуватися!
Ви можете використовувати npm run start щоб запустити вашу збірку в режимі спостереження, автоматично компілюючи ваш код кожного разу, коли ви вносите зміни у свій код і зберігаєте.
Ми дряпаємо поверхню
Фактичні блоки використовують бічну панель налаштувань редактора блоків та інші функції, надані WordPress, щоб створити багатий досвід користувача. Крім того, той факт, що існує фактично дві версії нашого блоку — edit та save — вам також потрібно подумати про те, як ви організуєте свій код, щоб уникнути дублювання коду.
Але, сподіваюся, це допоможе демістифікувати загальний процес створення блоків WordPress. Це справді нова ера в розробці WordPress. Важко вивчати нові способи роботи, але я з нетерпінням чекаю, як це розвиватиметься. Такі інструменти, як @wordpress/create-block допомогти, але навіть тоді добре знати, що саме він робить і чому.
Чи зміниться те, про що ми тут говорили? Швидше за все! Але принаймні у вас є базова лінія для роботи, оскільки ми продовжуємо спостерігати за формуванням блоків WordPress, включаючи найкращі методи їх створення.
посилання
Знову ж таки, моя мета тут — намітити ефективний шлях для початку блокової розробки в цьому сезоні, коли все розвивається швидко, а документації WordPress трохи важко наздогнати. Ось деякі ресурси, які я використовував, щоб об’єднати це:
