Drupal Composer рецепты

https://www.amazeelabs.com/en/node/1300
  • Перевод
В этом посте мы хотим поделиться некоторыми рецептами использования Composer, которые мы накопили работая с Drupal проектами созданными с помощью Drupal Composer template. Так же мы рассмотрим как перевести существующий Drupal проект на Composer.

Если вы до сих пор не используете Composer в Drupal проектах, вы должны начать делать это прямо сейчас! Drupal Composer template поможет с справиться с этой задачей. Создать новый проект — очень просто.

Если вы до сих пор не уверенны, взгляните на преимущества Drupal Composer разработки:

  • Нет необходимости хранить код контриб модулей (и само ядро!) в вашей системе контроля версий.
  • Единый инструмент управления пакетами для всего: ядро Drupal, контриб модули, JS библиотеки, ваши собственные модули используемые в разных проектах, и т.д.
  • Максимально простой и удобный патчинг ядра и модулей.
  • Это гораздо проще использования Git submodules.

(Все рецепты подразумевают использование Drupal 8, но они так же должны работать и для Drupal 7)

Установка контриб модулей


  • composer require drupal/<MODULE_NAME>:~8.0 что бы установить последний стабильный релиз (или последнюю dev версию, если релизов для Drupal 8 пока нет)
  • composer require drupal/<MODULE_NAME>:dev-<BRANCH_NAME> что бы установить последнюю dev версию
  • composer require drupal/<MODULE_NAME>:dev-<BRANCH_NAME>#<COMMIT_HASH> что бы установить конкретную версию

Обновление ядра Drupal и модулей


  • composer update что бы обновить всё
  • composer update --dry-run что бы проверить обновления
  • composer update drupal/<MODULE_NAME> что бы обновить конкретный модуль

Патчинг пакетов


Плагин cweagans/composer-patches (входящий в состав Drupal Composer template) использует патчи описаные в секции «extra» файла composer.json:

   "extra": {
       "patches": {
           "<PACKAGE/NAME>": {
               "<PATCH DESCRIPTION>": "<PATH/TO/PATCH/OR/URL>",
               ...
           },
           ...
       }
   }

Пример:

   "extra": {
       "patches": {
           "drupal/core": {
               "Fix language detection": "patches/2189267-24.patch"
           }
       }
   }

После того как патч добавлен, запустите:

  • composer install что бы применить патч
  • composer update nothing (или composer update --lock) что бы composer-patches плагин сделал необходимые изменения в файле composer.lock

Установка кастомных/форкнутых модулей с Github


Если репозиторий модуля содержит собственный composer.json файл


Зарегистрируйте репозиторий в секции «repositories» файла composer.json:

   "repositories": [
       {
           "type": "vcs",
           "url": "https://github.com/<REPOSITORY/NAME>"
       },
       ...
   ],

Используйте composer require drupal/<MODULE_NAME>:dev-<BRANCH_NAME>#<COMMIT_HASH> что бы установить модуль.

Если файл composer.json отсутствует в репозитории модуля


Используйте чуть более расширенный вариант:

   "repositories": [
       {
           "type": "package",
           "package": {
               "name": "drupal/<MODULE_NAME>",
               "version": "dev-custom",
               "type": "drupal-module",
               "source": {
                   "type": "git",
                   "url": "git@github.com:<REPOSITORY/NAME>.git",
                   "reference": "<BRANCH-NAME>"
               }
           }
       },
       ...
   ],

Используйте composer require drupal/<MODULE_NAME>:dev-custom#<COMMIT_HASH> что бы установить модуль.

Если целевая директория должна отличаться от modules/contrib


В дополнение к вышеприведённым рецептам, используйте composer/installers плагин:

   "extra": {
       "installer-paths": {
           "web/modules/custom/<MODULE_NAME>": ["drupal/<MODULE_NAME>"],
           ...
       }
   }

Установка JS библиотеки


Популярные JS библиотеки могут быть с лёгкостью установлены с помощью Composer, так как они (скорее всего) уже существуют в репозитории Packagist. Сложность заключается в том что большинство Drupal модулей требуют установки JS библиотек в директорию «libraries», в то время как Composer устанавливает их в директорию «vendor».

Плагин composer/installers может переназначать путь установки, но только для тех пакетов которые указывают его как зависимость. Таким образом, вам нужно подменить файл composer.json библиотеки, указав в нём зависимость от composer/installers.

Взглянем на пример:

   "repositories": [
       {
           "type": "package",
           "package": {
               "name": "enyo/dropzone",
               "version": "4.3",
               "type": "drupal-library",
               "source": {
                   "url": "https://github.com/enyo/dropzone.git",
                   "type": "git",
                   "reference": "master"
               },
               "dist": {
                   "url": "https://github.com/enyo/dropzone/archive/v4.3.0.zip",
                   "type": "zip"
               },
               "require": {
                   "composer/installers": "~1.0"
               }
           }
       },
       ...
   ],  
   ...   
   "extra": {
       "installer-paths": {
           "web/libraries/{$name}" : ["type:drupal-library"],
           ...
       }
   }

После того как этот код добавлен в composer.json, запустите composer require enyo/dropzone:4.3 что бы установить библиотеку. Заметьте что мы указали конкретную версию и добавили секцию «dist» что бы Composer мог загрузить zip архив вместо клонирования репозитория.

Переключаем существующий пакет на форкнутую версию


Зарегистрируете форк-репозиторий в composer.json:

   "repositories": [
       {
           "type": "vcs",
           "url": "https://github.com/<REPOSITORY/NAME>"
       },
       ...
   ],

Запустите composer require <PACKAGE/NAME>:dev-<BRANCH_NAME>#<COMMIT_HASH>

Переключаем существующий Drupal 8 project на Composer


  • Сделайте бекап ;)
  • Удалите всё чем будет управлять Composer: директорию «core» Drupal, контриб модули, и т.д.
  • Удалите все корневые Drupal файлы, такие как index.php, update.php, README.txt… Все их.
  • Создайте директорию «web» в корне проекта и переместите туда все оставшиеся Drupal директории (sites, modules, themes, libraries, profiles, и т.д.)
  • Скопируйте файлы Drupal Composer template в корень проекта.
  • Приготовьте список версий контриб модулей используемых в проекте, ядра Drupal и всего остального чем будет управлять Composer. Затем запустите composer require указывая конкретную версию для каждой зависимости. Вам понадобится перевести Drupal версии в Composer версии, вот несколько примеров:

    • drupal/core:8.1.8 тут всё сходится
    • drupal/admin_toolbar:8.1.15 поразумевает admin_toolbar 8.x-1.15
    • drupal/ctools:8.3.0-alpha26 поразумевает ctools 8.x-3.0-alpha26
    • drupal/config_installer:dev-8.x-1.x#a16cc9acf84dd12b9714def53be0ce280a5b0c1a поразумевает dev версию config_installer созданную из коммита a16cc9a бранча 8.x-1.x
  • В секции «require» файла composer.json измените версии ядра Drupal и контрибных модулей на "~8.0". Это сделает возможным будущие обновления.
  • Запустите composer drupal-scaffold, это создаст необходимые корневые Drupal файлы.
  • Убедитесь что ваш веб-сервер использует диркторию «web» в качестве web root.
Поделиться публикацией

Комментарии 12

    –5
    Чтобы перестать играться с Друпалом, достаточно подписаться на его список рассылки по безопасности.
      +3
      Я конечно не специалист по безопасности, но думаю что проблемы с безопасностью есть в любом софте. И если Drupal комьюнити предпринимает какие-то меры, например делает рассылки про найденые уязвимости, то это только плюс.
      +1
      Последняя серьёзная уязвимость в друпал 7 вроде была возможно создать много миниатюр одного изображения и переполнить hdd и это очень давно было, даже и не знаю это не самая плохая платформа у альтернативных решений проблем как правило больше и они другого порядка
        –3
        https://www.drupal.org/security — список проблем. Последняя была ровно месяц назад и раз в несколько месяцев появляются новые, причём только Drupal Core, в сторонних модулях — раз в несколько дней. И я считаю что это недостаток архитектуры, а не обычное состояние web проекта.
        0
        Чем этот подход принципиально отличается от использования drush? Я так понимаю, что держать весь сайт в гите не получится?
          +1
          В гите будут только конфиги и кастомный код. В этом вся прелесть.
            0
            Всегда можно держать весь сайт в гите. Но теперь этого не нужно, версионность в лок файле прописана.

            Использование компосера позволяет консистентно работать с зависимостями. Модуль точно так же прописан в компосер файле, как любой вендор компонент, который может вам понадобиться.
            0
            «И я считаю что это недостаток архитектуры, а не обычное состояние web проекта»

            Это на самом деле обычное состояние веб проектов к сожалению.

            И конечно это не имеет отношения к архитектуре, максимум к реализации. Как эти вещи вобще можно связать пробным образом не понимаю

            Там конечно больше проблем безопасности что и одна, но для такого проекта это не очень много и их фиксят, да а тому же это единственная цмс где действительно трудно протолкнуть что то опасное даже в каталог модулей ( кого попало не пропустят ) есть процедура апрува и так тесты для модулей, опять же идея песочницы модулей
              +1
              Приятно смотреть на то, что Drupal развивается в сторону более удобного использования.
                0
                Нет необходимости хранить код контриб модулей (и само ядро!) в вашей системе контроля версий

                Преподносится как преимущество №1. Но… в чём проблема держать ядро и контриб модули в своём репозитории?
                Места на терабайтном винте мало?
                Или может git clone c локального gitlab'a отработает медленнее чем git clone + composer install/update?

                Не воспринимайте как критику, это просто вопрос…
                  0
                  Не воспринимайте как критику, это просто вопрос…

                  Представим, что у вас есть сборка проекта под свои нужды, если она полностью лежит в git, то модули и ядро устаревают. Приходится или при выходе нового модуля сразу заменять его в git'e или оставить неактуальные версии и после git clone запускать drush up.


                  Оба варианта, по моему опыту, хуже работы через composer.

                  0
                  то модули и ядро устаревают

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

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

                  Наверняка после вышесказанного Вы захотите напомнить мне про composer.lock и про то что там зафиксированы версии… но, и в моём гите они тоже зафиксированы. Причём прям сами файлы.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое