14 ноября 2016 в 1:42
немного вольный перевод статьи:
https://www.lullabot.com/articles/goodbye-drush-make-hello-composer
от Karen Stevenson
Чтоб попробовать новые модули, темы Drupal 8, экспериментировать с новым функционалом, таким как миграции, мною строено-перестроено множество демо-сайтов на Drupal 8.
После длительных ручных установок Drupal 8, решено было взять и выяснить - как упростить это,
как создавать новые Drupal сайты с помощью Composer.
Это на самом деле очень удобный путь, подобный тому, как мы использовали Drush Make раньше; чтобы не хранить у себя код ядра и сопутствующих модулей Drupal, вы просто указываете, какие их версии вам нужны, и получаете их автоматически
Меня немного беспокоила перспектива смены привычного процесса, но мои опасения не оправдались. Тем, кто привык к Drush, скорей всего будет просто разобраться и с этим.
МНОГАБУКВ-НИЧИТАЛ*: Как в чистой директории, парой команд развернуть полностью функциональный Drupal сайт.
Установка Composer
Первый шаг - это установка Composer в вашей локальной системе.
Поглядите https://getcomposer.org/download/ для получения информации о том, как установить Composer.
Настройка проекта с Composer
Для создания нового Drupal проекта используя Composer, выполните следующие команды, где /var/drupal требуемое месторасположение кода:
composer create-project drupal-composer/drupal-project:8.x-dev drupal --stability dev --no-interaction
В процессе сборки загрузятся все модули ядра, Drush и Drupal Console, затем весь Drupal код будет помещен в поддиректорию web. Сторонний код будет помещен в vendor вне корневой web директории. Новая файловая структура выглядит следующим образом:
В конечном итоге, вы получаете в основе проекта composer.json файл, который выглядит следующим образом.
"name": "drupal-composer/drupal-project",
"description": "Project template for Drupal 8 projects with composer",
"type": "project",
"license": "GPL-2.0+",
"authors": [
{
"name": "",
"role": ""
}
],
"repositories": [
{
"type": "composer",
"url": "https://packagist.drupal-composer.org"
}
],
"require": {
"composer/installers": "^1.0.20",
"drupal/core": "8.3.*",
"drush/drush": "8.*",
"drupal/console": "~0.8",
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
"post-install-cmd": "scripts/composer/post-install.sh"
},
"extra": {
"installer-paths": {
"web/core": ["type:drupal-core"],
"web/modules/contrib/{$name}": ["type:drupal-module"],
"web/profiles/contrib/{$name}": ["type:drupal-profile"],
"web/themes/contrib/{$name}": ["type:drupal-theme"],
"web/drush/commands/{$name}": ["type:drupal-drush"]
}
}
}
Как вы видите в начале списка модулей в секции "зависимости" - Drush и Drupal console включены по умолчанию. Также вы видите, что согласно правил, сопутствующие модули расположены в подкаталоге /contrib.
Такая организация сайта происходит отсюда: https://github.com/drupal-composer/drupal-project/tree/8.x. README.md содержит описание процесса и действий, таких как обновление ядра. Сопутствующие модули получаются из Packagist а не из Drupal.org. Это обусловлено тем, что существующая система версионирования Drupal, не квалифицируется как семантическое версионирование, необходимое системе.
Дискуссия по поводу как это исправить, продолжается: https://www.drupal.org/node/1612910.
Установка Drupal
В полученном дистрибутиве собрана свежая версия Drupal 8.
Если у вас есть пустая база данных, вы можете немедля установить Drupal, используя Drush из этогоже дистрибутива:
Если вы не производите установку с помощью Drush, вам придется вручную сделать все, что Drush делает за вас.
Ручной процесс установки Drupal8 следующий:
- Скопировать default.settings.php в settings.php, и открыть для записи.
- Скопировать default.license.yml в license.yml , и открыть для записи.
- Создать и открыть для записи директорию sites/files
- Перейти по адресу EXAMPLE.COM/install для предоставления данных доступа к базе данных и следовать дальнейшим инструкциям.
Добавление дополнительных модулей из Packagist
Добавление дополнительных модулей происходит немного иначе. Вместо добавления модулей используя drush dl, дополнительные модули добавляются путем выполнения composer команд из корня проекта. (это на один уровень выше корневой директории Drupal):
composer require drupal/migrate_plus 8.1.*[user=dev]dev[/user]
По мере выполнения этих команд, каждый модуль будет загружен из Packagist, а
composer.json файл будет обновлен с добавлением соответствующей строки в список модулей.
Вы можете взглянуть на содержимое composer.json файла и увидеть, как эволюционирует секция зависимостей.
Делайте так, пока не добавите все необходимые дополнительные модули.
Такой composer.json файл будет эквивалентом Drush make файла, документирующего все ваши модули.
Для достижения еще большего паритета с Drush Make, вы также можете добавлять в composer.json сторонние библиотеки, и используя плагин, указывать необходимые патчи. Более подробно обо всех этих вариантах читайте https://www.drupal.org/node/2471553.
Фиксация файлов в репозитории
Зафиксируйте изменения composer.json в репозитории. Файлы, загруженные Composer, не нужны в репозитории. Гляньте содержимое .gitignore полученного из коробки. В вашем git репозитории будут сохранены только composer.json, .gitignore, код в /web/modules/custom и контент в /web/sites подкаталоге (кроме директории files).
vendor
web/core
web/modules/contrib
web/themes/contrib
web/profiles/contrib
# Ignore Drupal's file directory
web/sites/default/files
Обновление файлов
Для получения обновленных версий файлов в любое время, перейдите в корневую директорию Drupal и выполните в командной строке:
composer update
Для добавления дополнительных модулей, тем и библиотек, в любое время, выполните в корневой директории проекта используемую ранее команду:
composer require drupal/module_name 8.1.*[user=dev]dev[/user]
Это добавит еще одну строку в composer.json для соответствующего нового модуля. Теперь изменение composer.json должно быть зафиксировано и отправлено в репозиторий. Остальные инсталляции, в последствии будут принимать эти изменения, и получать новые модули в результате выполнения composer update.
Команда composer update должна быть запущена после каждой отправки или получения изменений от git репозитория. Таким образом, стандартная процедура для обновления из репозитория может быть следующей:
composer update
drush updb
Новый чекаут
В процессе нового обращения к этому репозиторию на другой машине, он просто клонируется, затем нужно будет перейти в созданную директорию и загрузить все зависимые модули, файлы и библиотеки следующим образом:
composer install
Это все
Итак, это все. По началу было немного стремно, но, как оказалось, этим очень легко управлять.
Вы можете использовать этот-же метод, с незначительными изменениями, для Drupal 7 сайтов.
Для своих нужд - измените 8.3.*dev из примера, на необходимые вам актуальные стабильные версии ядра и дополнительных модулей.
multpix: Конец статьи и мое небольшое дополнение
*TLDR (а также tldr и тлдр) — сокращение от too long; didn’t read (слишком длинно; не читал). Аналог фразы «многа букаф, ниасилил». Часто замещает «Резюмируя» после пространных объяснений, которые, как справедливо считает автор этих объяснений, не вся аудитория возжелает прочитать целиком, либо, наоборот, идет первым абзацем.
Полезные ссылки по теме:
Packagist The PHP Package Repository
Шпаргалка по Composer
Drupal Composer рецепты
Освоение Composer: советы и приемы использования
https://github.com/drupal-composer/drupal-project
https://www.drupal.org/docs/develop/using-composer/using-composer-with-d...
Drupal Composer
И помните главное правило:
Где не работает голова - там работают руки
Спасибо всем указавшим на опечатки и неточности в публикации 
Комментарии
Товарищи, если кто обратил внимание на неточности перевода, опечатки,
у кого возникли какие вопросы,
добро пожаловать в комментарии.
p/s
прошу воспринимать статью не как полное руководство к действию,
но как информацию к размышлению в нужном направлении,
не делать бездумный копипаст.
ответ экстрасенса на самый избитый и частый вопрос:
https://www.virtualbox.org/wiki/Downloads
https://www.linuxmint.com/
https://ru.wikipedia.org/wiki/Bash
https://ru.wikipedia.org/wiki/SSH
Вот так можно свои сборки распространять - публиковать их на GitHub/BitBucket,
а в README.md - подробную инструкцию по развертке.
С работой composer знаком чисто теоретически, но правильно я понимаю, что с его помощью можно без свистопляски с git submodules указывать некоторым модулям (патченным) обновляться со своего, кастомного репозитория, а не с орга? Да собственно, и своим модулям.
Второй вопрос - как это дело дружит со стандартным механизмом обновления. В плане - стандартную систему обновления наверное лучше отключать?
Отсюда получаем код
https://packagist.drupal-composer.org/
отсюда и обновляем
Практика будет лучше любых теорий)
поэкспериментируйте.
Установите ядро из ветки 8.1 и модуль какой-нибудь, тоже старой ветки.
Потом обновите до актуальных 8.2(или 3).
Вывод в консоли снимет массу вопросов.
Да вроде как людям понятны эти core, modules, themes и contrib/custom
Вот и кладут ))
├── autoload.php
├── core
├── index.php
├── modules
│ ├── contrib
│ └── custom
├── profiles
│ ├── contrib
│ └── custom
├── robots.txt
├── sites
├── themes
│ ├── contrib
│ └── custom
├── update.php
└── web.config
фломастеры)
upd:
хотя, возможно, с точки зрения человекочитаемости файловой структуры,
sites - это место для мультисайтинга, и разделения модулей специфичных для отдельных проектов,
а modules и themes в корневой - для одного проекта.
ох и долго же еще друпалу до Drupal on Rails)))
Никогда не известна наперёд дальнейшая судьба проекта. Вдруг через N лет дороги разработчика и заказчика окончательно разойдутся, выйдет критическая обновка, а заказчик захочет вручную обновить ядро. И тогда прощай весь кастомный код, если он не в sites.
Почему?
сотрутся modules/custom/* и themes/custom/* ?
и что-то произойдет с git репозиторием?
Как по мне - описанный метод как раз и позволяет избежать подобных казусов))))
Объясняю ситуацию:
2028 год. Сайт достался по наследству внукам заказчика. Вы решили поставить автоочистку своих репозиториев, в которых 10 и более лет не было никаких изменений. Сайт всё это время исправно работал. Но наступает очередной друпалгедон. Внуки заказчика думают, что надо бы обновить сайт. Контакты разраба остались в скайпе их деда, который завещал пароль внучке, которая с внуками не в ладах. Поэтому новоиспечённые хозяева сайта решают обновить по первой попавшейся инструкции из интернета, где написано "Удалите из корня сайта всё, кроме папки sites". Естественно папки modules, themes и .git отправятся на кладбище удалённых файлов. Далее последует паника, ругань, драки, и, возможно, даже слёзы. А всё потому, что кто-то решил не следовать общепринятоым правилам.
ого, сразу видно - не бодыль.
спасибо конечно, но я сегодня не буду, мне еще работать
)))
но ты побереги себя - хороших собеседников - по пальцам пересчитать.
Но ведь не просто так придумали структуру, что бесчинствовать можно только в sites, а остальное - священное ядро
Я попробую перевести это на русский.
Создавая свой код, привлекая код других людей,
вы должны дать себе ответ на следующие вопросы:
привлеченный в ваше приложение сторонний код - это ваш код или нет,
если не вы сопровождаете код - где его хранить и как собирать.
хранить, собирать
сейчас в php проектах для этого применяются два инструмента:
git и composer.
Мне тоже нравится этот подход, но я пока как кэлх тупо храню в гите весь сайт, кроме files.
Что касается фломастеров, я всё же настаиваю, что кастомный и контрибный код должен быть в sites. Потому что если он там, то обновить ядро сможет любой колхозник за 10 минут.
С другой стороны, чего париться о проблемах заказчика, который перестал с тобой сотрудничать?)))
семерка с годами того,а в восьмерке только папку core менять при обновляшке и весь контриб/кастом на месте
не только ее.
КАК КАЧНУТЬ ПАПКУ CORE???
пытаюсь перейти на трушный метод разработки, и с drupal 7 на drupal 8
собственно первое что привлекает это как раз возможность работать с гитом.
так вот ВОПРОС знатоки!
Поставил все через композер, инстальнул возможно даже добавил модли
drush site-install --db-url=mysql://{username}:{password}@Localhost/{database}
composer require drupal/token @stable
drush en token
все классно! далее гитнул это все дело, и перехожу на другой сервер(к примеру с локального на дев сервер)
Вот сделал
composer install
И папки core нет уже и там подпилял, и там, и то попробовал и се, а папки нет, как сделать через cli что бы она появилась?
тут в статье используется шаблон https://github.com/drupal-composer/drupal-project
не помешает изучить его док.
в корне созданного проекта делаем composer install
а то, что привыкли называть drupal root - это в кат. web, туда заходим только чтоб подрашить)
С установкой через композер проблем нет. Вопрос именно переноса проекта с одной машины на другую посредством git+composer использовая gitignore core сидит там, и при розворачивания по мануалу не подтягивается.
@Grenuy
в систему контроля версий - весь проект:
├── .gitignore
├── composer.json
├── composer.lock
├── config
├── drush
├── LICENSE
├── phpunit.xml.dist
├── README.md
├── scripts
├── vendor
└── web
├── autoload.php
├── core
├── index.php
├── modules
├── profiles
├── robots.txt
├── sites
├── themes
├── update.php
├── web.config
└── white.png
Дале:
cd PROJECT_NAME
composer install
gitignore имеет
core
vendor
вот вендер роворачиваеться, а core все никак... ( да и по логики должно было бы подтянуться, ведь везде одинаковый и с репы должно тянуться, да и что бы по трушному делать... Вот и ищу где что сделал не так, или чудо команду которая на новой машине, с которой подтянул проект с гита, что бы еще и подтянулся core
все работает в лучшем виде.
давай весь листинг из консоли, как эт делаешь
install на локальную машину
добавляем для теста несколько модулей
composer require drupal/metatag @stable
composer require drupal/pathauto @stable
composer require drupal/panels @stable
composer require drupal/linkit @stable
composer require drupal/module_filter @stable
далее добавляем .gitignore
.idea
# This file contains default .gitignore rules. To use it, copy it to .gitignore,
# and it will cause files like your settings.php and user-uploaded files to be
# excluded from Git version control. This is a common strategy to avoid
# accidentally including private information in public repositories and patch
# files.
#
# Because .gitignore can be specific to your site, this file has a different
# name; updating Drupal core will not override your custom .gitignore file.
# Ignore core and vendor when managing dependencies with Composer.
core
vendor
modules/contrib
themes/contrib
profiles/contrib
# Ignore configuration files that may contain sensitive information.
sites/*/settings*.php
sites/*/services*.yml
# Ignore paths that contain user-generated content.
sites/*/files
sites/*/private
!sites/default/files/config_*/sync/
# Ignore SimpleTest multi-site environment.
sites/simpletest
# If you prefer to store your .gitignore file in the sites/ folder, comment
# or delete the previous settings and uncomment the following ones, instead.
# Ignore configuration files that may contain sensitive information.
# */settings*.php
# Ignore paths that contain user-generated content.
# */files
# */private
# Ignore SimpleTest multi-site environment.
# simpletest
vendor/doctrine/common/lib/vendor/
vendor/guzzlehttp/guzzle/build/
vendor/guzzlehttp/guzzle/docs/
vendor/guzzlehttp/guzzle/tests/
#Would skip repository libraries/dropzone
#libraries/composer.json
далее заливка на гит
git commit -m "Bla bla"
git push
Устанавливать пока не обязательно, позже буду, хотя бы движок развернуть что бы работало
далее уже в новой папке
composer install
все... вендор появился, модуля так же, core нет.
cd PROGECT_NAME
git init
git add -A && git commit -m "initial"
git remote add origin REMOTE_REPO/PROJECT_NAME
git push -u origin master
откуда то еще
cd PROJECT_NAME
composer install
Распространяем весь проект, в его корне работаем с composer
(не в web, в котором друпал и куда нацелен вебсервер)
# Ignore directories generated by Composer
/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/
# Ignore sensitive information
/web/sites/*/settings.php
/web/sites/*/settings.local.php
# Ignore Drupal's file directory
/web/sites/*/files/
# Ignore SimpleTest multi-site environment.
/web/sites/simpletest
# Ignore files generated by PhpStorm
/.idea/
С этим работает
composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
А вот с офф не работает
composer create-project drupal/drupal dir 8.*@stable
Жаль.. Будем пока жить не с официальным
спасибо!
все нормально, этож гитигнор используемого шаблона
Причина не только в нем, а в строении папок файлов, с офф репы, папки web нет
Я советую почитать конфиг шаблона - там ответы на все незаданные вопросы)
Помогите дилетанту, как заставить испонятся команды с помощью drush и consol. Вот к примеру что бы запустить команду
composer updateя пишуphp /путь к установленому композеру/composer.phar update.Здесь разобрался, а вот запустить упоминавшеюся здесь команду
drush updbне получается, тоже наверное требуется прописать путь к drush и что нибудь ещё. Здесь было упомянуто следующее«Установка Drupal
В полученном дистрибутиве собрана свежая версия Drupal 8.
Если у вас есть пустая база данных, вы можете немедля установить Drupal, используя Drush из этогоже дистрибутива:
cd drupal/web
../vendor/bin/drush site-install --db-url=mysql://{username}:{password}@Localhost/{database}
»
но тогда по логике в папке vendor должна лежать папка bin в которой должен лежать drush, у меня в папке vendor папки bin нет, а папка drush лежит в корне сайте как здесь и показано на картинке.
То же самое и с drupal consol.
Допустим хочу выполнить команду
drupal update:debug, но если напишу так не сработает. Написано что drupal consol лежит в папке bin в корне, открывал этоу папку, там какие то ссылки, файлов нет, и я не знаю как это использовать, короче помогите, как заставить работать драш и друпал консольЕсли есть надобность использовать drush, работать с ними нужно из корня drupal,
в нашем случае это каталог web.
Или использовать ключ --root=АБСОЛЮТНЫЙ_ПУТЬ_К_ДРУПАЛ
Шаблон, о котором речь в статье,
https://github.com/drupal-composer/drupal-project
изначально включает в себя drush и drupal-console
Убедиться в этом можно глянув composer.json.
(Если нет - добавить эти пакеты ключем require)
После развертки, все зависимости нужно установить ключем install.
В bin лежат линки на исполняемые скрипты, к примеру drush:
drush* -> /FULL/PATH/TO/PROJECT/vendor/drush/drush/drushТак-же возможно использовать абсолютный путь к скрипту, для его запуска.
А каталог drush/ - для его оперативной работы, там нет исполняемых.
С друпал консолью разобрался, спасибо. С драшем не до конца. Я установил версию друпала с друпал комерцем возможно в этой версии драша в комплекте нет, в composer.json о нём упоминается только в строках
"type:drupal-drush"
]
}
Особой нужды в драш у меня нет, но всё таки хочется знать, как его установить, надо редактировать composer.json или устанавливать через командную строку
http://www.drush.org/en/master/install/
Спасибо, понял.
Имхо, собирая дру с composer и этим шаблоном, используя drupal-console - необходимости в drush нет.
А способ установки дополнительных модулей через композер, например:
composer require drupal/token @stableлучше чем добавление модулей дедовским методом через админ панель сайта?
Просто мне легче по старинке, я не очень дружу с командной строкой. Есть ли разница с точки зрения функционирования сайта?
Разница принципиальнейшая. Простенький модулёк может и установится так, но очень многие модули требуют сторонних библиотек, которые нужно не только скачать, но и добавить в autoload.php, если вы попробуете сделать это вручную, то поймёте, что быстрее будет разобраться с композером)))
Одно дело дело держать в репозитории весь код друпала и контрибных модулей и совершенно другое - один единственный конфигурационный файл композера.
Нет, не понимаю о чём Вы говорите. Догадываюсь что речь идёт о git. Изучаю его сейчас, смотрю курсы от lynda. И какой репозиторий? Свой собственный на своём хостинге или какой нибудь общак? И зачем это, имея конфигурационный файл композера можно восстановить сайт при его падении?
Не надо путаться)
Вы используете шаблон организации проекта на базе drupal.
https://github.com/drupal-composer/drupal-project
В этом шаблоне зависимости вашего проекта (ядро, контриб модули, библиотеки, патчи) обслуживаются composer-ом.
Вы можете хранить свой проект в системе контроля версий (авторы шаблона рекомендуют git), в шаблоне уже присутствует .gitignore файл,
из содержания которого вам ясно, что версировать вы будете две вещи:
1. свой код.
2. список сторонних зависимостей.
3. возможно, состояние своего приложения (конфиги).
Т.е. храня и перемещая проект, вы по факту - храните только свои уникальные наработки.
Первейшее практическое применение - деплой проекта.
В демонстрационную/тестовую ли стадию,
в продакшн ли - у вас это может быть одна команда git push КУДА КАКАЯ_ВЕТКА
которая и проект выгрузит со всеми зависимостями, и дернет нужные git хуки,
в которых может быть все что угодно: тесты, миграции бд, применение конфигов, и пр.
https://git-scm.com/book/ru/v1/Настройка-Git-Перехватчики-в-Git
Это не восстанавливает сайт после падения, а они сами не падают - в 99% случаев упасть им помогают их разработчики)
Это не решает вопросы бекапа контента.
Это автоматизирует процесс разработки и обслуживания проекта.
А правильно ли я понял, если у меня установлен какой нибудь модуль и вышла его новая версия, и я хочу его обновить, то надо просто выполнить команду
composer updateдаже не указывая какой модуль, композер сам его найдёт и обновит?
Композер обновит только код.
Все обновления (/update.php и дочерние зависимости) так и остаются на плечах разработчика.
update.php - конешн, применение миграций, не имеет отношения к получению кода,
а дочерние это кто?
Я про зависимые от обновляемого модули. Если апдейтить меж мажорами - может слететь какая апиха.
Ааа) главное не фигачить так в продакшене)))
В среде разработки - доводить до рабочерго а потом тем-же гитом на сервак и собирать уже проверенное.
@vinta вот таки прийдеться разобраться с тем как указываются версии в composer.json
https://getcomposer.org/doc/04-schema.md
да и вообще - весь его док.
В принципе - да.
Это обновит весь список,
но можно указывать и конкретную цель.
https://github.com/drupal-composer/drupal-project#updating-drupal-core
В composer.lock заглянуть - там полный список того что уже есть.
(править его не нужно - создается автоматом)
Но, однозначно - эта статейка и ветка обсуждений, это только старт.
Полюбому вникать нужно самостоятельно.
Очень обширный материал.
Я на всяк случай ссылки полезные в конце перевода собираю,
Если найдешь чего интересного, кидай в коменты, разберем.
То есть если я захочу конкретно обновить модуль token, надо писать
composer update drupal/tokenа ещё лучше:
composer update drupal/token --with-dependencies?
Немного насчёт update.рhp
Как я упоминал ранее, есть сборка друпал комерца для установки через композер, и в документации по обновлению самого комерца написано, что лучше чем update.рhp выполнять команды друпал консоли
drupal update:execute
уж не знаю хорошо это или плохо, но вот они пишут так.
https://github.com/drupalcommerce/project-base - это шаблон
структура проекта которую он создает очень отличается от того, что получаем с дефолтным коробочным компосером.
если пользуешься шаблоном - читай док к шаблону)
Может не по теме, но очень близко:
Имею:
VPS сервер на котором есть 2 (и более) пользователей, у каждого, стандартно, своя директория веб-сервера, папка www, где лежат папки сайтов.
Сайты у обоих пользователей на drupal 7. Git репозитории хранятся на уровень выше сайтов, т.е. директория сайта www/site.ru, директория git репозитория для него www/git/site.ru.
В репозитории весь проект, вместе с ядром..., contrib модулями..., кроме sites/*/files, sites/*/private.
Разрабатываю-тестирую всё на локале, далее по этой инструкции https://habrahabr.ru/post/151997/ выталкиваю на продакшн, там же в hook post-receive очищается кеш, базу обновляю в ручную, но думаю можно было и туда же прописать drush команду.
Если мультисайтинг, то делаю всё также, только используя алиасы сайтов.
Сейчас перехожу на drupal 8 и хочется немного улучшить эту архитектуру!
Можно ли как-то ядро и контриб модули вынести вообще в сторонний каталог, доступный для обоих пользователей, чтобы при этом иметь возможность обновлять код ядра и модулей и базы всех сайтов и хранить в репозиториях только свой кастом, и может, конфиги?
Сейчас много чего читаю и про гит-сабмодули и про composer, а тут ещё рекомендуют выносить папку с конфигами на уровень выще папки сайта? Как это всё собрать воедино? )))
Может кто что-нибудь посоветует?
Воплне себе реализуемо и даже удобно.
Сам думал о том-же: каталог с конфигами для 8-ки убрать из веб.
Тут об этом: http://drupal.ru/node/130460
Суть проста, в settings.php (или settings.local.php) указываем путь где размещены конфиги.
Т.е., без проблем использовать
../configА в этой ветке, я предлжил свой перевод интересной на мой взгдяд статьи, и погнали обсуждать.
Речь идет о шаблоне организации проекта на друпал (отличном от того что имеем в коробке).
https://github.com/drupal-composer/drupal-project
(на нем же базируется шаблон для коммерца: https://github.com/drupalcommerce/project-base)
Считаю такую организацию весьма практичной и удобной.
У реп хороший док, тут для старта на рус., если есть вопросы или предложения - в коменты.
По сабжу - я бы пересмотрел такую организацию как у вас ))
Но направление верное - мы храним только свой код.
Я бы делал так:
разработал - отправил ветку с фитчей в удаленную репу,
проверили - смерджили с девелопмент веткой,
набралось - оформили релиз,
забрали(или отправили) релиз на продакшн.
Свой код и конфиги в гите, все остальное - композитором (достаточно глянуть .gitignore этого шаблона).
Для вебсервера корневым указываем каталог web нашего проекта.
Все.
Для меня сейчас непонятен момент с пользователями.
Я не очень силен в linux...
Если вынести папки ядра из директории пользователей, необходимо будет завести пользователя под эти нужды, не от root же обновлять потом? И не будет ли проблем с доступом к ним?
это уже вопросы организации кода на продакшн
как вам такой вариант:
для работы с кодом сайтов - один пользователь deployer
в его дом каталоге сайты, на них нацелен вебсервер
владелец файлов - deployer, вебсервер добавлен в группу
(http://help.ubuntu.ru/wiki/стандартные_права_unix)
каждый сайт - полный пак всех необходимых файлов со всей структурой каталогов
переносить (между машиной разработчика, хранилищем кода, тестовыми стендами, производственным сервером) с git толко свой код,
сторонний собирать уже на месте композитором (это можно автоматизировать теми-же хуками https://git-scm.com/book/ru/v1/Настройка-Git-Перехватчики-в-Git).
и только обслуживать вебсервер - с админ правами (добавить сайт, перезапустить и пр.)
еще может будет полезным узнать о таком подходе:
http://drupal.ru/node/131184
как будет время про CI еще наваяю - мне эта тема самому интересна.
Мне необходимо, чтобы владельцами сайтов были разные пользователи!
Считаю, что это и по безопасности правильно, тем более, если владельцы сайтов - разные.
Ну разработа то на локале вся ведется, там тоже же ядро и контриб обновлять надо!
Т.е., если правильно понял, можно совместить 2 рецепта (в этой статье и в http://drupal.ru/node/130460).
и
Git в таком случае будет отвечать только за кастом и конфиги а за ядро и контриб - composer.
А как добиться, чтобы ядра и контриба вообще в проекте не было, ну т.е. чтобы они лежали отдельно а в проекте только ссылки на них были. Такое возможно?
возможно то все, но надо ли)))
мы ведь так просто получаем этот код в проект - одна команда и вуаля - все на месте.
А обновлять потом ядра каждого сайта в отдельности?
А так можно было бы один раз обновить всё сразу!
Безусловно обновлять(и хранить), ядро и модули для каждого проекта надо отдельно.
Есть очень не нулевой шанс, что вам понадобятся, например, разные мажорные версии модулей для разных проектов.
Модули может быть, но ядро, вряд ли! % так 99
Апдейт ядра может что-то у вас сломать. Это не уникальная ситуация, такое бывало и в 6 и в 7 ветке.
И вполне, может возникнуть необходимость, на одном сайте, апдейт ядра накатить, а не другом, решить проблему, или дождаться апдейта какого-нибудь модуля, и только потом накатить.
Ничего хорошего, в одном ядре для пачки сайтов нет. Место - это экономия на спичках. А проблем в поддержке покинуть такая экономия может в полный рост.
Я подозреваю, что это займет больше времени.
Да и место на диске занимать один и тот же код будет.
Может можно как-то симлинками организовать?
и тут на помошь придет друпал
если хотите избежать дублирования кода - используйте мультисайтинг
но у вас следующий вопрос возникнет - два пользователя...
ответ - два мультисайтинга)
возможно спросите - так у каждого же по одному сайту...
ответ - тогда зачем такие сложности)))
но попробуйте использовать ссылки,
тут вам нужно будет основательно переработать этот шаблон, если хотите имено его использовать так,
настоятельно рекомендую пробовать не на продакшен,
и помимо помощи форума - проработать этот вопрос со своим сисадмином.
а с результатами - это ведь будет хорошая тема для публикации в ваш блог здесь)))
Спасибо, буду пробовать, отпишусь обязательно.
Еще вопросик, вот я начал делать сайт, куча модулей подключил все хорошо, в гит за пушил, все отлично, колега с гита пулыть, розворачивает, и тут вопрос, как можно автоматично включать\выключать модуля, и передавать эту инффу в гит(я знаю что можно через DRUSH en\dis но как сделать что бы какие именно модуля включились выклчюились в гит передать?
)
На восьмёрке для этого достаточно сделать экспорт и импорт конфигурации. Т.е. перед пушем, вернее перед git add запускать drush cex, а сразу после пулла запускать drush cim
активция и настройки какого-то модуля - это настройки которые хранятся в БД
в 8-ке их можно описывать с помощью конфигов
(т.е. выносим описание конфигурации в файл, который можем хранить в системе контроля версий)
подробней про конфиги здесь: http://drupal.ru/node/130460
То как пробывал, все настройки хорошо летают, но отключения\включения модулей приходиться доп. командами DRUSH (настройки этих модулей норм синкаються через гит)
такого не заметил,
активируются при импорте соотв конфига без всяких драшей)
Ну, даже не знаю, что написать. Сколько работаю - не было у меня подобных ситуаций, слава Богу.
Но даже если и будет, то что помешает,для какого-то одного, конкретного сайта своё-нужное ядро положить?
как принцип,
у самодостаточного изолированного проекта - все же больше плюсов чем минусов.
в тех же рельсах - гемы не лежат в проекте, но мы можем указывать для конкретного проекта специфические версии,
использовать тот-же rvm, делать гемсеты, и это снимает массу проблем.
в вашем случае - нужно исходить из задачи,
если есть необходимость мониторить и управлять роем друпалбасед сайтов - стоит подумать о какой то внешней системе администрирования и мониторинга.
а о вынесении общих частей в третье место для совместного использования - я бы начал думать, если бы у меня стояла проблема лимита индексных дескрипторов на каком нить шаред хостинге.
разумеется, это всего-лишь мое скромное мнение))
А мне вот например версия 7.39 нет-нет, да и приснится в кошмаре.
всякое бывает...
Но в моем случае, мне удобнее, будет иметь одно ядро отдельно от проектов.
Вы просто не обновляли реально рабочие проекты с 8.2 на 8.3.
Обновлял...
Значит, повезло)))
Это просто говорит о том, что вам повезло, или вы не своевременно обновлялись.
Лучше использовать сразу хороший подход, а не придумывать костыль в процессе решения проблемы.
Никакого реального смысла и пользы в использовании одного ядра/модулей для разных проектов просто нет. А минусы есть.
Какие минусы?
Самые очевидные описаны выше.
ИМХО, здесь всё индивидуально для каждого конкретного случая!
Вот только, 21:58 11.06.2017 Занёс руку, написать , что перехожу на друпал 7. Но после непростых бэкапов
Вдруг сайт загрузился, но с таким вот. Друпал 7, конечно, он тоже проблемный. Но !
Fatal error: Allowed memory size of 269484032 bytes exhausted (tried to allocate 16777216 bytes) in /home/host1318833/spbmapo.org/htdocs/www/core/lib/Drupal/Component/Transliteration/PhpTransliteration.php on line
То есть утечка памяти. А в php.ini у меня 256 mb
Но поскольку я простой уч. врач, то до этого мне не дойти ни умом, ни без него.
А началось с бутстрап, потом начал расширяться. Потом на хабре попалась такая статейка. Drupal 8. Обучающие материалы и не только
Автор Олег Кот. После чего всего, я понял, что я попал не в хорошую компанию. Я ведь просто как юзер, загрузил сайт.
Да, драш, проходил, не нужен он точно теперь. Инструментов предостаточно других.
Подскажите, если уже есть проект без композитора. Как его правильно поставить на сие рельсы?
Подскажите как быть с библиотеками, например, модуля colorbox, как делать чтобы композер их тоже подгружал?
Композер, все же, менеджер PHP-пакетов. Но, не удивлюсь если есть инструменты для интеграции и других зависимостей.
А также, не стоит забывать о директиве scripts.
Colorbox - JS (Jquery) библиотека. Ее можно контролировать с помощью специализированных pm (npm, bower). И это уже, скорее, дела фронтендерские.
Также, если речь идет именно о модулях Drupal, большинство разработчиков предусматривают возможность загрузки библиотек с помощью Drush. Например для Colorbox, библиотеку можно загрузить командой
drush colorbox-pluginДля других - читайте документацию к модулю.
Нашёл: некоторые библиотеки уже есть в packagist
colorbox: https://packagist.org/packages/onlyextart/colorbox
composer require onlyextart/colorbox
Ну, это на свой страх и риск.
Можно только надеяться что автор пакета будет держать в репозитории актуальную библиотеку.
Ну, и это скорее костыль, чем решение, т.к. убивает саму идею контроля пакетов. Лучше уж так.
с такой логикой - сам подход на свой страх и риск
Я не про риск использования "чужих" пакетов, а про риск получения не актуальной библиотеки.
Тогда совсем не понимаю! Модули то тоже берутся из packagist...
Модули берутся с орга.
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
}
В дополнение^: https://www.drupal.org/docs/develop/using-composer/using-packagesdrupalorg
а чем так лучше то? Тем что репа на гитхабе?
Тем что это официальный репо либы.
А как быть, например, с библиотеками ckeditor? В них нет packcage.json
В репе проекта и так не будет библиотек, исходя из этого https://github.com/drupal-composer/drupal-project/blob/8.x/.gitignore
/web/libraries/
Доброго всем времени суток!
Извиняюсь за ньюбский вопрос.
Есть:
ОС Ubuntu с Apache 2.4
В системе работаю под своим юзером.
Сайт Drupal 8 установлен композером в директорию /var/www/мой сайт. Установка производилась от своего юзера, после чего, для корректной работы сайта права на директорию переопределены юзеру www-data.
При попытке установить дополнительный модуль композером, получаю сообщение "web/modules/contrib/дополнительный_модуль does not exist and could not be created." т.к. у текущего юзера нет прав на директорию.
И что делать? Каждый раз при установке модуля переопределять права на директрорию или есть какие-то другие варианты?
Или я что-то не понимаю?
usermod -a -G www-data $USERПремного благодарен! Линукс тоже ещё осваиваю, упустил из виду возможность добавления юзера в группу.