Некоторое время назад, чтобы перевести свой контрибный модуль на русский язык нужно было положить файл перевода с расширением .po в каталог translations модуля. Сейчас алгоритм перевода немного изменился и сегодня рассмотрю новый актуальный способ перевода.

Нужен действующий аккаунт на https://drupal.org

В последнее время стала популярна тема статических сайтов. И действительно: если сайт - это лендинг или сайт-визитка, где контент не обновляется вообще или обновляется раз в месяц, то зачем хранить на хостинге целую систему CMS? Например, наш сайт https://why.drupal.ru сделан на друпале, но на хостинге находится именно статический набор HTML, CSS и изображений.

К сожалению, мигратор метатегов из модуля 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

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