Начало работы с разработкой блоков WordPress

WordPress продолжает удерживать статус самой популярной системы управления контентом (CMS) благодаря своей гибкости и мощным функциональным возможностям. Одним из значимых новшеств последних лет стало внедрение редактора Gutenberg, который привнёс концепцию блоков в редактирование контента. Они позволяют пользователям и разработчикам создавать сложные макеты и дизайны страниц с легкостью. В этой статье мы рассмотрим, как начать разрабатывать для WordPress.

Основы блоков в WordPress

Прежде чем начать разработку, важно понять, что такое блоки WordPress и как они функционируют в экосистеме CMS. Блоки — это элементы интерфейса, которые пользователь может вставлять, настраивать и перемещать в редакторе. Каждый может содержать различные типы контента, такие как текст, изображения, кнопки или видео.

Компоненты

• HTML-структура: основа, определяющая его содержимое и функции.
• CSS-стили: внешний вид на странице.
• JavaScript: поведение, включая интерактивные элементы.

Первые шаги в разработке блоков

Установка необходимых инструментов

Для начала разработки необходимо установить несколько инструментов:

1. Node.js и npm: среда выполнения JavaScript и менеджер пакетов, необходимые для работы с современными инструментами разработки.
2. WordPress: CMS, на которой будет тестироваться разрабатываемый блок.
3. Редактор кода: Visual Studio Code или другой предпочтительный редактор.

Использование create-block

После установки необходимых инструментов рекомендуется начать с использования утилиты @wordpress/create-block. Этот инструмент позволяет быстро создавать стартовый шаблон для нового блока:

npx @wordpress/create-block my-custom-block

Эта команда создает базовую структуру, включая все необходимые файлы для начала работы.

Процесс разработки

Приступая к разработке, важно следовать следующим шагам:

1. Определение функционала: четко определите, что будет делать ваш блок и какие настройки он будет предлагать.
2. Проектирование блока: создайте макет, включая структуру и стили.
3. Кодирование: напишите код HTML, CSS и JavaScript для реализации задуманного функционала.
4. Тестирование: проверьте его в различных условиях, убедитесь, что он корректно работает на всех поддерживаемых устройствах и браузерах.
5. Оптимизация: улучшите производительность, уменьшите время загрузки и ресурсы, которые он использует.

Пример проекта

Давайте создадим пример проекта для разработки простого блока ВордПресс, который будет показывать пользовательское приветствие с настраиваемым текстом и фоном. Этот блок будет использовать базовые технологии: HTML для структуры, CSS для стилизации и JavaScript для интерактивных элементов.

Подготовка среды

Убедитесь, что у вас установлены Node.js и npm. Затем установите WP на ваш локальный сервер (например, используя XAMPP или MAMP) и выберите редактор кода.

Создание структуры блока

Откройте терминал и выполните следующую команду для создания нового блока:

npx @wordpress/create-block custom-greeting-block

Эта команда создаст каталог custom-greeting-block с начальной структурой проекта.

Создание блока

Откройте папку проекта в вашем редакторе кода. В файле src/index.js начните с добавления следующего JavaScript кода:

import { registerBlockType } from '@wordpress/blocks';
import metadata from './block.json';
import './style.scss';

import { RichText, InspectorControls, ColorPalette, useBlockProps } from '@wordpress/block-editor';

import { PanelBody } from '@wordpress/components';

registerBlockType(metadata.name, {
apiVersion: metadata.apiVersion,

title: 'Custom Greeting',

icon: 'smiley',

category: 'design',

attributes: {

content: {

type: 'string',

source: 'html',

selector: 'h2',

},

backgroundColor: {

type: 'string',

default: '#f0f0f0' // light gray as default background color

}

},

edit: ({ attributes, setAttributes }) => {

const { content, backgroundColor } = attributes;

const blockProps = useBlockProps();

return (

<>

<InspectorControls>

<PanelBody title="Background Color">

<ColorPalette

value={backgroundColor}

onChange={(color) => setAttributes({ backgroundColor: color })}

/>

</PanelBody>

</InspectorControls>

<RichText
{...blockProps}
tagName="h2"

value={content}

onChange={(newContent) => setAttributes({ content: newContent })}

placeholder="Enter greeting text..."

style={{ backgroundColor }}

/>

</>

);

},

save: ({ attributes }) => {

const { content, backgroundColor } = attributes;

return (

<RichText.Content {...useBlockProps.save()} tagName="h2" value={content} style={{ backgroundColor }} />

);

},

});

Стилизация

Добавьте CSS в файл src/style.scss, чтобы улучшить визуальное представление:

.wp-block-create-block-custom-greeting-block {

padding: 20px;

text-align: center;

border-radius: 8px;

}

5. Сборка и тестирование

Перейдите в терминал вашего проекта и запустите:

npm start

Это автоматически соберет ваш блок и отслеживает изменения в файлах. Теперь вы можете активировать плагин в админ-панели WP и начать использовать свой новый блок на страницах и записях.

Это базовый пример, который можно расширить, добавляя дополнительные функции и опции, такие как выбор шрифтов или добавление кнопок. Этот проект предоставляет хорошую отправную точку для дальнейшего изучения и экспериментов с разработкой блоков WordPress.

Заключение

Разработка собственных блоков для WordPress открывает огромные возможности для создания уникального и функционального контента на вашем сайте. Следуя представленным рекомендациям и используя современные инструменты, вы сможете значительно расширить возможности вашего сайта и предложить пользователям улучшенный опыт использования.

Имя блока и файлы сборки: проверка custom-greeting-block

Редакционный пример

Старый пример в разделе 5 создаёт каталог custom-greeting-block без флага --namespace, но регистрирует блок как custom/greeting. По умолчанию create-block использует namespace create-block, поэтому имя блока в block.json и в вызове registerBlockType может не совпасть с ожидаемым. Кроме того, если полностью заменить src/index.js, легко потерять импорт ./style.scss — тогда стили не попадут в сборку. Ниже — компактный чекер, который сравнивает исходный и собранный block.json, проверяет клиентскую регистрацию и наличие локальных файлов. Шаблон составлен редакцией, данные условны; методическая основа — официальная документация WordPress, ссылки даны по тексту. (По данным developer.wordpress.org).

Чекер check-greeting.cjs

// Условный пример. Запуск:
// node check-greeting.cjs <SRC_DIRECTORY> <BUILD_DIRECTORY>
const fs = require('fs');
const path = require('path');

const [srcDir, buildDir] = process.argv.slice(2);
if (!srcDir || !buildDir) {
  console.error('Укажите каталог источника блока и каталог сборки блока');
  process.exit(2);
}

const readJson = (p) => JSON.parse(fs.readFileSync(p, 'utf8'));
const srcMeta = readJson(path.join(srcDir, 'block.json'));
const buildMeta = readJson(path.join(buildDir, 'block.json'));

const errors = [];

// 1. Имя блока в исходном и собранном block.json
if (srcMeta.name !== buildMeta.name) {
  errors.push(`name не совпадает: src=${srcMeta.name}, build=${buildMeta.name}`);
}

// 2. Клиентская регистрация использует metadata.name
const indexJs = fs.readFileSync(path.join(srcDir, 'index.js'), 'utf8');
if (!/registerBlockType\(\s*metadata\.name/.test(indexJs)) {
  errors.push('index.js не вызывает registerBlockType(metadata.name)');
}

// 3. Импорт style.scss сохранён
if (!/import\s+['"]\.\/style\.scss['"]/.test(indexJs)) {
  errors.push('index.js не импортирует ./style.scss');
}

// 4. Локальные editorScript/style: значения вида file:./имя, путь относительно каталога block.json
for (const field of ['editorScript', 'style']) {
  const raw = buildMeta[field];
  if (!raw) {
    errors.push(`в block.json сборки нет поля ${field}`);
    continue;
  }
  if (typeof raw !== 'string' || !raw.startsWith('file:')) {
    errors.push(`${field}: поддерживается только строковая локальная ссылка вида file:./имя`);
    continue;
  }
  const abs = path.join(buildDir, raw.slice('file:'.length));
  if (!fs.existsSync(abs)) {
    errors.push(`файл ${field} не найден: ${raw}`);
  }
}
if (!fs.existsSync(path.join(buildDir, 'index.asset.php'))) {
  errors.push('в каталоге сборки нет index.asset.php');
}

if (errors.length) {
  console.error('Ошибки:');
  errors.forEach((e) => console.error(' - ' + e));
  process.exit(1);
}
console.log('ok: имя, регистрация и файлы сборки согласованы');

Условные результаты четырёх локальных проверок

Как исправить старый пример

В block.json задайте name как custom/greeting и используйте это же значение через metadata.name в registerBlockType — так рекомендует официальная документация по метаданным блока. В src/index.js сохраните import './style.scss'. В edit передайте useBlockProps() на RichText с tagName="h2", в save — useBlockProps.save() на RichText.Content. Стиль ограничьте классом блока, например .wp-block-custom-greeting. Поля editorScript и style в block.json указывают пути относительно самого block.json; style подключается и в редакторе, и на фронтенде. PHP-регистрация через register_block_type принимает путь к каталогу с block.json. (По данным developer.wordpress.org). (По данным developer.wordpress.org).

После успешной сборки активируйте плагин в собственном локальном WordPress и самостоятельно проверьте наличие h2 и стилей. Редакция не запускала сборку, не активировала плагин и не проверяла аккаунт.

Ограничения

Чекер проверяет один блок и явно указанные каталоги; универсальная поддержка всех шаблонов не обещана. Значения SRC_DIRECTORY и BUILD_DIRECTORY зависят от раскладки вашего scaffold — шаблоны могут размещать блоки в подпапках.

Частые вопросы

Почему имя блока в block.json и в registerBlockType должно совпадать? Если имена различаются, WordPress регистрирует блок под одним именем, а метаданные описывают другое. Это затрудняет поиск блока в редакторе и может привести к ошибкам при сохранении. Проверка сравнивает name в исходном и собранном block.json и вызов registerBlockType(metadata.name).

Что будет, если в index.js нет импорта style.scss? Стили не попадут в сборку, и блок отобразится без оформления. Чекер ищет строку import './style.scss' и сообщает об ошибке, если импорт отсутствует.

Зачем проверять index.asset.php в каталоге сборки? Этот файл создаётся сборщиком и содержит список зависимостей и версию. Без него WordPress может не подключить скрипты блока корректно. Чекер проверяет его наличие в указанном каталоге сборки.