Замечание: статья по большей части уже не актуальна, с версии 8.8.0 в друпал наконец-то завезли работающий composer-project.
Всё чаще стали предлагать работу на Drupal 8, а я ещё толком за него и не брался. Дай думаю для начала создам свой профиль и переведу блог на восьмёрку, благо совсем недавно вышла версия 8.4.
Начать решил по традиции с скрипта автоматической установки. Уже вбив в sh файлик заветное drush dl drupal
вспомнил, что для восьмёрки нужен свежий Drush, несовместимый с версией для Drupal 7. Иду на drush.org → Docs → Install и вижу:
Проблема 1: друпал нельзя скачать с помощью Drush
Сайт встречает заметной плашкой:
Drush 9 only supports one install method. It requires that your Drupal 8 site be built with Composer and Drush be listed as a dependency.
Т.е. друпал должен быть установлен с помощью Composer, а Drush добавлен локально в качестве зависимости. Глобальная установка не поддерживается, но есть отдельная утилита drush-launcher, которая по сути просто перенаправляет команды в vendor/bin/drush
.
Вспоминаю о Drupal Console:
Проблема 2: CLI утилиты теперь две
Существует альтернатива Drush под названием Drupal Console. Первоначально она задумывалась как код-генератор, но сейчас по факту клон Drush.
Что же выбрать? Мои фоловеры в твиттере предпочитают Drupal Console. Я пожалуй теперь буду тоже. Хотя ничто не мешает установить и то и другое.
И Drupal Console тоже можно установить только локально...
Ладно, двигаюсь дальше. Гуглю "drupal install composer". Вторая же ссылка ведёт на официальную документацию, где и правда советуют ставить друпал с помощью композера. Но:
Проблема 3: установка через Composer возможна тремя различными способами
Для скачивания друпала предлагается на выбор три варианта:
1. composer create-project drupal-composer/drupal-project
2. composer create-project drupal/drupal
3. с помощью утилиты hussainweb/drupal-composer-init
Это была бы не проблема, если бы все три варианта давали один результат, но результат будет разниться.
Основные отличия кроются в организации каталогов. В drupal-composer/drupal-project
и hussainweb/drupal-composer-init
папка vendor
вынесена за пределы web root, что требует дополнительной настройки сервера.
Остановится решил на втором способе (как выяснится позже - ошибочно), чтобы результат был похож на оригинальный дистрибутив друпала. Выполняю в консоли composer create-project drupal/drupal
. Друпал скачался, один в один, как в дистрибутиве.
Читаю документацию дальше. Выясняю, что модули и темы теперь надо ставить тоже с помощью композера — composer require drupal/modulename
. Необходимость в Drush начинает пропадать.
Подобный подход позволяет забыть о ручном копировании дополнительных библиотек, требующихся для работы некоторых модулей. Композер сам скачает/обновит все зависимости. Раньше таким занимался drush make.
А sandbox модули ставятся так же просто? Нет:
Проблема 4: sandbox модули ставятся через костыль
Друпаловский композер-репозиторий packages.drupal.org
ничего не знает о sandbox-ах. Это значит, что для установки каждого sandbox модуля, нужно дополнительно добавлять в composer.json
соответствующий git-репозиторий:
composer config repositories.modulename git "https://git.drupal.org/sandbox/username/123456.git"
composer require drupal/modulename
Сразу встаёт вопрос — как же обновлять всё это добро? Простое копирование затрёт изменённые файлы композера и возможно положит сайт. Документация однозначного ответа не даёт, описана только процедура обновления модулей: composer update drupal/modulename --with-dependencies
, про обновление ядра пусто. Лезу в гугл. Везде советуют composer update drupal/core --with-dependencies
. Ок, выполняю и:
Проблема 5: из коробки невозможно обновить Drupal с помощью Composer
Композер ругается:
Package "drupal/core" listed for update is not installed.
Пакет drupal/core
добавлен в composer.json
в секцию replace
, поэтому его нельзя обновить с помощью композера. Гуглю, попутно бомблю в твиттер. Нахожу статью Troubleshooting Composer и мою проблему. Советуют изменить composer.json
и перенести пакет drupal/core
из секции replace
в секцию require
. Но:
Проблема 6: composer не может удалять пакеты из секции replace
В композере нет команды для удаления пакета из секции replace
. Поможет только ручная правка composer.json
.
Вручную, так вручную. Удаляю "drupal/core": "^8.4"
. Выполняю composer require drupal/core
. Всё отлично, ядро теперь можно обновлять. Главное не забыть после обновления файлов запустить update.php
или выполнить vendor/bin/drush updb
.
Как обновить сразу всё — ядро и модули? На drupal.org не советуют, но по идее composer update
. Выполняю и:
Проблема 7: "composer update" обновляет зависимости ядра даже когда этого не надо
composer update
обновляет зависимости ядра, даже когда само ядро ещё не обновилось, т.е. оно с ними не оттестировано и теоретически могут возникнуть трудновоспроизводимые проблемы.
Коллеги в твиттере посоветовали композер модуль webflo/drupal-core-strict. Ставим — composer require webflo/drupal-core-strict
. Теперь composer update
не обновляет пакеты из core/composer.lock
, зато обновляет другие зависимости. Возможно не зря советовали не выполнять глобальный update. Как тогда за раз обновить овер сто модулей вопрос открытый.
В твиттере же всплывает:
Проблема 8: файлы вне папки core не обновляются
Файлы index.php
, robots.txt
и другие, которые не находятся в папке core
, не обновляются при вызове composer update drupal/core
или даже composer update
.
Проблема решается установкой очередного композер-модуля drupal-composer/drupal-scaffold: composer require drupal-composer/drupal-scaffold
.
По умолчанию модуль будет выкачивать все файлы из дистрибутива, которые находятся вне папки core
, в том числе robots.txt
и .htaccess
, что нежелательно. Чтобы ограничить список файлов, нужно изменить опцию extra.drupal-scaffold.excludes
. У композера есть команда для изменения настроек в секции extra, но:
Проблема 9: composer не умеет сохранять массивы в качестве значения опции
В extra.drupal-scaffold.excludes
нужно сохранить массив файлов. Команда composer config
этого сделать не может.
Вручную добавляем в секцию extra
:
"drupal-scaffold": {
"excludes": [
".htaccess",
"robots.txt"
]
}
Теперь при обновлении версии ядра друпала, будут обновляться "scaffold" файлы, за исключением .htaccess
и robots.txt
.
Проблема 10: при обновлении композер не может разрулить конфликты
При попытке выполнить composer update
он начнёт выдавать дурацкие сообщения о том, что не может разрулить конфликты зависимостей. Помогает удаление нескольких строчек из конфига:
"include": [
"core/composer.json"
],
Теперь всё. Друпал скачан и готов к установке с последующим обновлением (не факт).
Получившийся скрипт:
#!/usr/bin/env bash
composer create-project drupal/drupal . --no-dev
php -r '
$composer = json_decode(file_get_contents("composer.json"), true);
unset($composer["replace"]);
unset($composer["extra"]["merge-plugin"]["include"]);
$composer["config"]["optimize-autoloader"] = true;
$composer["extra"]["drupal-scaffold"]["excludes"] = [".htaccess", "robots.txt"];
file_put_contents("composer.json", json_encode($composer, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES));
';
composer require --update-no-dev \
drupal/core \
webflo/drupal-core-strict \
drupal-composer/drupal-scaffold \
drush/drush \
drupal/console
vendor/bin/drupal site:install standard \
--db-type=mysql \
--db-name=drupal8 \
--db-user=mysql \
--db-pass=mysql \
--account-name=admin \
--account-pass=admin \
--account-mail="admin@localhost" \
--site-name="Drupal 8" \
--site-mail="admin@localhost" \
--langcode=ru \
--force
На самом деле есть ещё небольшая проблема. У меня почему-то всегда выкачиваются пакеты из секции require-dev
. Я перепробовал миллион комбинаций и запретить скачивание никак не получается. Помогает только удаление composer.lock
перед вызовом composer require
.
Как итого. На дворе 2017 год. После релиза восьмёрки прошло два года. Дрис при каждом случае рассказывает про небывалые высоты, которых они достигли в DX. А я трачу выходные, чтобы правильно скачать (не установить!) Drupal 8. Вообще давно назревает продолжение статьи про свинью в помаде (старожилы вспомнят), но после такого нужно хлопать дверью, к чему я пока не готов :) Посему продолжаем!
Комментарии
drupal-composer/drupal-project
, де-факто, "правильный" вариант.Получается что проблемы 4, 5 и 6 относятся только к шаблону drupal/drupal который мало кто использует.
Если шаблон drupal-composer/drupal-project не подходит, то можно очень легко сделать свой (займёт ~15 минут).
composer create-project xandeadx/drupal-project
часть 1
А я полюбил композер, хотя по началу также недоумевал.
- Удобная система зависимостей, которая также умеет качать сторонние зависимости. Без композера это бы приходилось делать руками, так как ложить third-party либы с модулем на орге вроде как запрещено.
- Удобная система патчинга, которая сама патчит при обновлении и предупреждает что патч уже не подходит.
- Для создания нового проекта достаточно перекинуть composer.json от старого. Либо уже посмотреть в сторону drupal-project, я пока всё приглядываюсь и походу скоро решусь взять его. Хотя это и потребует изменения конфигов nginx на сервере, но это походу самый удобный вариант.
- Размер репозитория для D8 очень минимизирован, так как все контрибы, ядро и прочие зависимости подтягиваются композером.
- Возможность удобно подключать свои или чужие репозитории. Например GitHub проект для своих нужд. В composer.json будет всё предельно ясно и видно, откуда тащится, по каким критериям и куда ставится. Также композер поддерживает их в актуальном состоянии, если требуется.
- Композер умеет детектить изменения в момент обновления. Он может заметить что в файлы с кодом вносились изменения и предлагает несколько вариантов на выбор: обновить с заменой, оставить изменения, подготовить патч для изменений. Это очень удобно, хотя полностью перекрывается патчингом. Но если кто-то со стороны начудит, хотя бы не перетрется.
- Композер имеет свои "хуки" где можно писать свои команды или даже код под свои нужды. Можно задать чтобы после апдейта он делал drush updb, или же бекапил БД перед апдейтом.
часть 2
То что ты написал, да, минусы, но они с лихвой перекрываются плюсами которые дает композер. Подобные проблемы, как мне кажется, все же исправят или все перейдут на drupal-project.
Единственный не совсем очевидный момент, особенно для новичков, будет то, что проект лучше изначально полностью собирать через композер. Страница на drupal.org об этом умалчивает. Хотя надо брать пример с симфони, оставить возможность загружать только композером и решать проблемы из-за которых появляются drupal-scaffold. Для тех, кому интересен код, есть git репозитории. Никаких установок модулей драшем, никаких ручных установок с загрузкой по FTP (разве что для кастома), никаких установок из админки. Как по мне, установку модулей надо удалять из админки, и если хотят оставить инструменты, делать модуль с UI под композер.
Композер уже де-факто стандарт в 8-ке. Многие модули уже просто не поставить без него: Commerce, Search API, ImageMagick ещё какие-то популярные также имеют зависимости от либ которые качаются композером и грузятся его автолоадом. Когда человек на 8-ке нарвется на композер, вопрос лишь времени, и чем больше модулей переписывают заново под 8-ку, тем больше становится модулей которые ставятся только композером.
Сейчас улучшения должны пойти быстрее. Drupal 8.4+ поддерживается только Drush 9, там уже нет возможности качать модули, только включать и отключать. На dru.io мы даже специально блочили эту команду для старого драша. Осталось дождаться когда соберутся и потрут установку из админки через wget.
Не без недостатков, но после 2-3 проекта от композера остаются только приятные впечатления.
Полностью поддерживаю слова Niklan и рекомендую использовать https://github.com/drupal-composer/drupal-project во всех новых проектах. А так же переносить существующие под контроль composer.
drupal-composer/drupal-project – (© @vaplas) это здорово, пользуйтесь – не пожалеете.
Что касается /web/index.php - это легко решается небольшой подстройкой сервера. Только дописать /web к root директории.
А все свои модули можно успешно ставить через packegist.org
Конечно большое внимание стоит уделить при передаче проекта. У меня был случай когда я отдал бекап сайта.. На его структуру внимания не кто не обратил и обновили классическим способом перезаписав файлы поверх.. Всегда нужно смотреть в composer.json и проверять что это там стоит.
тоже поддержу Niklan: использую https://github.com/drupal-composer/drupal-project
вроде нет проблем.
Если уж совсем привыкли к тому, чтобы не было промежуточной папки web, то можно решить вопрос правкой composer,json. Например вот так:
@Вячеслав, ещё в autoload.php нужно будет путь исправить и сам composer.json переместить в document root.
P.S. Никто не сказал какой composer тормозной по сравнению с
drush dl
.да, точно, не нашел ссылок тут про composer global require hirak/prestissimo . Все равно медленнее, но уже не так катастрофично)
hirak, hirak и в продакшен
я уже сбежал с этого титаника :) переходите на octobercms
Чтобы сбежать, нужно было сначала попасть туда.
Может вы там и не были вовсе ?
Отличный коммент )))
"Получившийся скрипт:"
Как вы его запускаете ?
Через консоль open-server не получилось.
попасть куда?
я сделал на drupal много сайтов за последние 4-5 лет, но не вижу больше смысла его использовать, он хуже october'a и технически, и в плане админки.
Сайты в студию! А мы оценим на предмет качества.
И не надо в блоге, уважаемого в сообществе человека, откровенно рекламировать какой то "самопис" 3-x авторов с платными модулями.
И что вы здесь потеряли? Сбежавших крыс на бал не приглашали.
В первую очередь Вы должны спросить себя знает ли консоль open-server что такое composer
Нет?
Заглянуть сюда https://getcomposer.org/doc/00-intro.md#installation-windows
А лучше всего завести себе VPS с Ubuntu или аналогом. Настроить себе окружение: nginx, mariadb, php7, composer, drush, drupal. И радоваться жизни.
ИМХО: open-server для школьников. И лично я
и близко не видел у себя ничего подобного.
Это bash скрипт. На винде можно запустить с помощью Cygwin или msysgit.
Спасибо за статью!
@cyberlex404 Lex M., с composer они знакомы, а вот код
php -r ' ...
не даст выполнить в таком виде.Приведенный пример актуален для drupal/drupal
Выше в комментариях мы уже рекомендовали использовать drupal-composer/drupal-project. Работает замечательно и без бубна.
@cyberlex404 Lex M., не пойму, зачем вы это пишите ?
Ограничения с консолью open-server уже прояснились.
извините, а вы вообще кто?
при желании, по указанному мною нику гуглится аккаунт на drupal.ru, а там есть ссылка на портфолио.
с это довольно странно, что вы так эмоционально привязаны к движку, это все лишь инструмент для решения конкретных задач, у которого есть плюсы и минусы, а не религия, от которой нельзя отречься. И еще раз извиняюсь, я не знал что ваше величество ввело цензуру в блоге уважаемого автора.
Парни, прекращаем офтоп.
https://github.com/drupal-composer/drupal-project - все таки этот вариант более правильный, используем на куче проектов и никаких проблем
А вот мультисайтинг порезали похоже под D8. Он то работает, но с композером не дружит. И документации 0.
Коллеги, а что на данный момент наиболее правильно будет делать после создания проекта через Composer?
Я ставил текущую версию 8.4.2, используя первый (и основной, как я понимаю) вариант:
composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
Посмотрел статью "Goodbye Drush Make, Hello Composer!", там рекомендуют либо
т.е. воспользоваться Драшем (??), либо вручную:
Но статья двухлетней давности, с учётом более полной интеграции Композера в Друпал и сокращения функций Драша, хочется понять как действовать правильно дальше, чтобы всё идеально работало, когда переход на Композер станет полным.
Отдельно отмечу, что у меня виртуальный хостинг, но доступ по SSH есть и с памятью вроде не так плохо.
Установить друпал "неправильно" нельзя. Нравится drush - ставьте им, нравится install.php - ставьте из браузера, результат будет один.
Я понимаю, что вы имеете в виду: при "традиционной" установке (когда index.php в корне и т.д.) действительно, различий нет.
Но вот я, как и вы, тоже решил, что "лучше день потерять, потом за час долететь" и начал копать Композер. В процессе чтения стало понятно, что люди регулярно сталкиваются с затыками, т.к. есть неочевидные вещи.
Вот и сейчас, с учётом активно меняющейся ситуации, связанной с переходом на Композер, мне не совсем понятно, всё ли я делаю верно, с учётом того, что дальше придётся пользоваться только им?
Может быть за два года ситуация поменялась и даже при установке надо что-то учесть?
Я, например, пока ещё чувствую себя неуверенно при работе с Композером и предпочёл бы сделать сразу с заделом на будущее, чем потом разбираться с проблемами.
Присутствие композера никак не влияет на способ и процесс установки друпала. Композер управляет зависимостями и всё.
А процесс установки никак не может повлиять на композер и его дальнейшую нормальную работу?
А то я до этого 8-м друпалом не пользовался, только 6-м много лет назад.
Разумеется, сначала попробовал "обычную" установку. Так там, если не ошибаюсь, после ввода юзера/пароля/имени базы бежит прогресс бар, т.е. вполне возможно, что установка не только базу наполняет.
Не может.
Спасибо, всё получилось установить через SSH, после пары взмахов бубном сайт заработал.
Однако не могу удержаться, чтобы узнать у вас ещё кое-что.
Я использовал другой вариант установки (
drupal-composer/drupal-project
), но думаю, что этот момент у нас общий:У меня на шаред хостинге композер выставил странные разрешения на файлы и папки.
Например, у папок стоят 775, у файлов (в т.ч. .php) - 664, у autoload.php - вообще 666.
Я пока у /web/index.php и /web/ их не поменял, вообще получал Internal Server Error.
Как было у вас? Такая ситуация нормальна?
@Сергей
Что касается прав на папки композер делает все верно (права ставит скрипт внутри шаблона) скорее всего это проблема конфигурации хоста на сервере. (Лично у меня на своем vsp такой проблемы не было).
Я еще раз повторюсь: composer - это только менеджер пакетов. Он не как не влияет на работу $drush и $drupal , но забирает у них роль "скачивателя" модулей, тем и прочих библиотек.
Для обновления кода котрибных пакетов Вы используйте composer, а для работы с drupal из консоли: $drush or $drupal or etc.
Drush 8 вполне себе ставит Drupal 8
На дворе 2020, мало что изменилось в лучшую сторону. Похоже Дрис крутит друпал в сторону своего бизнеса(Acquia), ему не нужны конкуренты.
Почему же, с версии 8.8 с композером всё в порядке, друпал ставится одной командой
Установка может быть, но вот переход с 7 на 8 версию, это ужос. Мне как чайнику установить семерку было очень просто. С 8 версией проблемы начинаются уже с выбора хостинга, да и работа с командной строкой не добавляет юзабилити системе. Минус отсутствие многих модулей для 8-й версии, что также говорит о снижении популярности друпала 8-й версии. Imho
Если говорить про снижение популярности среди чайников, вы правы
Добавить комментарий