Мой первый опыт разработки Gutenberg блока — плагин Ext Link Block

Мой первый опыт разработки Gutenberg блока — плагин Ext Link Block

Недавно задумал сделать плагин, который позволяет вставлять ссылку в пост, закрывая ее от поисковиков чтобы не терять вес. Плюс подсчитывать количество переходов.

Похожий плагин уже был сделан для WooCommerce https://wpcraft.ru/product/woopee/

Сел делать и понял что с Gutenberg все не так просто 🙂 уже нельзя взять просто добавить метабокс и расслабиться. Как это было раньше и как было сделано в плагине для WooCommerce.

Теперь нужно писать блоки. И это меня с одной стороны напрягло, а с другой стороны — это отличный повод освоить новый блочный редактор для WordPress.

В итоге получилось вот это: https://wpcraft.ru/product/ext-link-block/

Далее пройдусь по основным инсайтам/граблям…

Нужен React и вся прелесть современного JavaScript

Да, пришлось чуть освоить React. С компонентным подходом и реактивностью. Правда пока по минималке. Обошелся ES5 без npm & Webpack с примерами из руководства на сайте WordPress: https://wordpress.org/gutenberg/handbook/designers-developers/developers/tutorials/javascript/

Но это потому что блок очень простой. Далее придется налаживать полный комплект:

  • генератор блока из wp cli: https://wordpress.org/gutenberg/handbook/designers-developers/developers/tutorials/block-tutorial/generate-blocks-with-wp-cli/
  • npm + babel + webpack

Во многом причина в том что ES5 еще можно писать без них, но примеров мало.

А большинство примеров и код ядра написан на ESNext, который без всей этой кухни запустить просто не удалось.

Но пока обошлось без них и это радует.

Конструкторы блоков

Уже появляются конструкторы блоков, включая популярный ACF. Они сильно упрощают такие задачи, но влекут за собой зависимости. А мне хотелось прочувствовать все на кончиках пальцев, потому решил копать вглубь и пока обойтись без зависимостей.

Все быстро меняется

Нашел доки типа таких: https://code.tutsplus.com/ru/tutorials/wordpress-gutenberg-block-api-creating-custom-blocks—cms-31168

Но они уже устарели 🙂 Например часть про параметр useOnce — использовать блок только 1 раз на странице. Мне он как раз был нужен. И он не заработал. Оказалось что его уже переименовали и перетащили в опцию supports.

Хранить данные теперь можно как в мете, так и в post_content

Вот это очень прикольная идея. Были проекты где на 1 пост приходилось по 5000 метаполей, потому что все оформление хранили через ACF. А оформление было сложным.

На самом деле большинство данных нет нужды хранить в метаполях. Это просто контент и какие то тексты, которые нужны для страницы. Gutenberg может все это хранить прямо в post_content, получать и сохранять обратно через селекторы.

Это клевая возможность.

Однако в моем случае ссылку надо было полюбому хранить в метаполе, чтобы потом подключить 301 редирект с переходом по ней. И это тоже можно.

Причем можно сделать так что у блока на 3 поля, 2 будут храниться в HTML, а 1 в метаполях.

Выводы

Пожалуй это очень большой скачок сложности в мире WordPress за последние 5 лет. Не помню чтобы была какая то потребность сильно менять багаж знаний за эти годы. А тут надо теперь прям глубоко и жестко погружаться в JS, React, npm, babel, Webpack … 🙂

У этой записи один комментарий

  1. Добро пожаловать в мир гутенблоков))
    Я на своем сайте несколько вещей подробно описывал. Но не реклама — а так — поделился.

Добавить комментарий

Закрыть меню
×

Корзина