Интеграция Gutenberg в WordPress 5

Технический обзор интеграции редактора Gutenberg в WordPress 

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

Для лучшего понимания интеграции Gutenberg в WordPress, разберемся, как устроен плагин Gutenberg.

Пакеты JavaScript

Плагин Gutenberg по своей сути это JavaScript приложение, построенное на нескольких пакетах. Каждый из этих пакетов:

• Типовой и доступен как npm пакет.
• Плагин Gutenberg регистрирует каждый пакет как скрипт WordPress.
• Плагин Gutenberg делает публичный API каждого пакета доступным в глобальной переменной wp.
• Если пакет зависит от другого пакета, он  поглощает его как глобальную переменную, и добавляет его как зависимость зарегистрированного скрипта WordPress.
• Пакет может иметь один или несколько таблиц стилей CSS.

Например:

Пакет npm @wordpress/components зарегистрирован в плагине как скрипт WordPress wp-components; его API доступно в глобальной переменной wp.components; и зависит от @wordpress/element.

В свою очередь, скрипт @wordpress/element это wp-element и поглощается @wordpress/components в общем скрипте как wp.element.

Загрузка страницы редактора

Для отображения страницы редактора мы вызываем wp.editPost.initializeEditor из пакета более высокого уровня wp-edit-post. Эта функция принимает как аргумент текущую запись и некоторые настройки редактора.

Этот вызов производится во время загрузки страницы edit.php, где локализуются требуемые аргументы и подключается скрипт wp-edit-post.

Конечные точки REST API

Как только страница редактора отобразилась, все коммуникации с WordPress происходят с помощью вызовов REST API. В дополнение к стандартным конечным точкам REST API для получения, обновления, удаления таксономий, записей и т.д., Gutenberg добавляет новые конечные точки REST API:

• Конечная точка Автосохранения.
• Конечная точка Повторяемых блоков (Reusable Blocks).
• Корневая конечная точка для настроек сайта.

Множество других поправок были необходимы в существующих конечных точках (таксономиях, вставках, постоянных ссылках, поиске записей, и т. д.) и большинство из них были поглощены в предыдущих релизах 4.9.* 

Метабоксы

Для поддержки метабоксов хуки Gutenberg в самом начале отображали контент метабоксов в скрытой ноде DOM, отрендеренной с помощью PHP скрипта. Также мы цепляемся к вызову post.php для осуществления вызова сохранения метабоксов.

Итог

Итак, в общем плане плагин Gutenberg состоит из:

• Скриптов JavaScript и стилей.
• Файла PHP для начальной загрузки редактора в edit.php.
• Конечных точек REST API.
• PHP утилит для разбора, регистрации и отображения блоков на фронтенде.
• PHP скриптов для инъекций метабоксов на страницу и хуков для сохранения метабоксов.

(adsbygoogle = window.adsbygoogle || []).push({});

Процесс интеграции

На предыдущих встречах по JavaScript мы обсуждали подходы к интеграции пакетов:

Так как скрипты JS созданы как повторно используемые пакеты npm, мы будем использовать их в WordPress как и любые другие пакеты npm:

• Добавляя зависимость в package.json ядра.
• Экспортируя глобальные переменные wp.* в подключаемые скрипты внутри ядра WordPress.
  • Пример: wp.components = require( '@wordpress/components' );
• Перемещая регистрацию скриптов в соответствии с каждым пакетом в wp-includes/script-loader.php.

Скрипты, такие как wp.shortcode, wp.a11y.speak, wp.utils.WordCount могут быть заменены соответствующими им пакетами npm. Это нововведение уже было предложено для пакета шорткода и должно быть применено к остальным пакетам.

Результат работы, проделанной на собраниях #core-js для приведения в соответствие рекомендаций по стилю кода JavaScript между Gutenberg и ядром, должен оформиться в официальный пакет  @wordpress/eslint-preset, который должен будет заменить текущий конфиг JSHint.

Конечные точки REST должны будут перенесены в стандартное расположение конечных точек в ядре WordPress  wp-includes/rest-api/endpoints.

Утилиты PHP и классы будут перемещены в wp-includes.

Некоторые минорные задачи еще осталось завершить в репозитории Gutenberg:

• Убрать имя Gutenberg из всех API PHP, которые используют его.
• Завершить пакеты block-library и edit-post :
  • Блок HTML и Freeform переместить в пакеты npm.
  • Создание пакета edit-post.

Тестирование

Тестирование e2e критически важно для избежания регрессии при внесении изменений в WP-Admin. Инфраструктура e2e тестирования и тесты сами по себе должны быть перенесены в ядро WordPress, и их стабильность должна быть мерилом успеха процесса интеграции.

Модульные тесты, в общем случае, находятся рядом с тестируемым кодом. Тесты для пакетов останутся в репозитории Gutenberg, тесты для файлов, переносимых в ядро, перейдут вместе с ними.

Что будет с плагином Gutenberg?

После релиза WordPress 5.0 плагин Gutenberg будет продолжать существовать. Его задачей станет разработка и поддержка пакетов npm WordPress, включая сам редактор. Он также будет использоваться для разработки второго этапа проекта Gutenberg — настройки и кастомизации сайта. Обновления плагина будут выходить на протяжении жизненного цикла WordPress 5.0.

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