К сожалению, мигратор метатегов из модуля metatag не всегда корректно срабатывает. В моём случае он отказался работать и метатеги не перенеслись вместе с контентом. Быстро был найден простой вариант:

Задача: миграция метатегов из модуля metatags_quick в модуль metatag

Этот материал будет Вам полезен, если совпали следующие условия:

1. Файлов очень много и их объем занимает десятки гигабайт
2. Канал передачи файлов имеет низкую скорость
3. У вас уже есть архив с файлами старого сайта
4. Новый сайт в докере и вам лень создавать для файлов дополнительные контейнеры или монтировать их внутрь имеющихся контейнеров

Всё что нужно сделать, это положить файлы в корень проекта вот так

К сожалению, я не осилил модуль webform_migrate. Вернее "из коробки" он ничего не делал, документация очень скудная и даже нет примеров использования.

В поисках информации я наткнулся на репозиторий https://github.com/JAyenGreen/webform_d7_to_d8

Это модуль для Drupal 8. Я кинул его в /modules/custom и включил на сайте. Далее по шагам:

В последнее время эта тема довольно популярна, но особо нигде нет достаточно информации. Поделюсь своим опытом.

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

Для чего вообще может понадобиться деплой контента? Ситуации бывают разные. Например, вам нужно сделать страницу, блок, пункт меню на деве, а потом сделать так, чтобы оно появилось на проде. А доступа к проду у вас нет, потому что клиент - банк, со всеми вытекающими. Или когда над сайтом одновременно работают много человек и таскать с дев сервера базу на локалку надоедает. Ну или вы, хитрец, взяли БД с прода, чтобы внести необходимые правки (добавить термины таксономии, изменить пункты меню), а пока вы делали, клиент добавил 100 товаров на сайт и вы не можете теперь вашу БД загрузить обратно на прод (да и это не самая хорошая идея, в принципе).

На этом вступительная часть окончена.

Задался я сегодня вопросом, как на drupal.org делают "красивые" release notes. Например https://www.drupal.org/project/jsonapi/releases/8.x-2.1

Красивость в том, что номер issue является ссылкой на issue, а имя пользователя ссылкой на пользователя. Плюс есть разделение по типу issue (bug, task, feature)

Выяснилось, что есть инструмент помогающий в этом. Это drupalorg-cli

Пример использования:

Решил ознакомиться с темой статических сайтов и сделать небольшой decoupled (он же headless) Drupal сайт с фронт-ендом, полностью написанным на React — https://z-portfolio.tk.

Изначально для реализации задуманного я выбрал Next.js, но в процессе работы неприятно удивил целый ряд недостатков и костылей. Пришлось отказаться от Next в пользу свежевышедшего Gatsby.js ver 2.

Итак, вы решили поделиться своим модулем с сообществом, но не знаете с чего начать? Давайте разбираться вместе.

1. Для начала нужно завести аккаунт на drupal.org. Это обычная процедура, как и на многих сайтах.

2. Попав в личный кабинет, нужно перейти в раздел Your Projects и там уже есть ссылка Add a new project.

Block API в Drupal 8 была изменена таким образом, что сейчас блоки являются плагинами(plugins) и сущностями(entities) одновременно. Блоки в Drupal 8 совмещают в себе две разных API структуры: Block Plugin API, которое является автономным повторно используемым API, и Block Entity API, которое представляет собой конкретный вариант использования блока и управление его видимости. Это означает, что блоки теперь являются объектами с полями и работают с новой системой плагинов введенной в Drupal 8.