Прощай Drush Make, Привет Composer!

Главные вкладки

Аватар пользователя multpix multpix 14 ноября 2016 в 1:42
8

немного вольный перевод статьи:
https://www.lullabot.com/articles/goodbye-drush-make-hello-composer
от Karen Stevenson

Karen Stevenson

Чтоб попробовать новые модули, темы Drupal 8, экспериментировать с новым функционалом, таким как миграции, мною строено-перестроено множество демо-сайтов на Drupal 8.

После длительных ручных установок Drupal 8, решено было взять и выяснить - как упростить это,
как создавать новые Drupal сайты с помощью Composer.

Это на самом деле очень удобный путь, подобный тому, как мы использовали Drush Make раньше; чтобы не хранить у себя код ядра и сопутствующих модулей Drupal, вы просто указываете, какие их версии вам нужны, и получаете их автоматически

Меня немного беспокоила перспектива смены привычного процесса, но мои опасения не оправдались. Тем, кто привык к Drush, скорей всего будет просто разобраться и с этим.

МНОГАБУКВ-НИЧИТАЛ*: Как в чистой директории, парой команд развернуть полностью функциональный Drupal сайт.

composer create-project drupal-composer/drupal-project:8.x-dev drupal --stability dev --no-interaction
cd drupal/web && ../vendor/bin/drush site-install --db-url=mysql://{username}:{password}localhost/{database}

Установка Composer
Первый шаг - это установка Composer в вашей локальной системе.
Поглядите https://getcomposer.org/download/ для получения информации о том, как установить Composer.

Настройка проекта с Composer
Для создания нового Drupal проекта используя Composer, выполните следующие команды, где /var/drupal требуемое месторасположение кода:

cd /var
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 из этогоже дистрибутива:

cd drupal/web
../vendor/bin/drush site-install --db-url=mysql://{username}:{password}localhost/{database}

Если вы не производите установку с помощью 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_upgrade 8.1.*[user=dev]dev[/user]
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).

# Ignore directories generated by Composer
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 репозитория. Таким образом, стандартная процедура для обновления из репозитория может быть следующей:

git pull
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

И помните главное правило:
Где не работает голова - там работают руки

Спасибо всем указавшим на опечатки и неточности в публикации Smile

Комментарии

Аватар пользователя multpix multpix 14 ноября 2016 в 2:51

Товарищи, если кто обратил внимание на неточности перевода, опечатки,
у кого возникли какие вопросы,
добро пожаловать в комментарии.

p/s
прошу воспринимать статью не как полное руководство к действию,
но как информацию к размышлению в нужном направлении,
не делать бездумный копипаст.


ответ экстрасенса на самый избитый и частый вопрос:
https://www.virtualbox.org/wiki/Downloads
https://www.linuxmint.com/
https://ru.wikipedia.org/wiki/Bash
https://ru.wikipedia.org/wiki/SSH

Аватар пользователя multpix multpix 14 ноября 2016 в 2:06

Вот так можно свои сборки распространять - публиковать их на GitHub/BitBucket,
а в README.md - подробную инструкцию по развертке.

Аватар пользователя fairrandir fairrandir 14 ноября 2016 в 11:54

С работой composer знаком чисто теоретически, но правильно я понимаю, что с его помощью можно без свистопляски с git submodules указывать некоторым модулям (патченным) обновляться со своего, кастомного репозитория, а не с орга? Да собственно, и своим модулям.

Второй вопрос - как это дело дружит со стандартным механизмом обновления. В плане - стандартную систему обновления наверное лучше отключать?

Аватар пользователя multpix multpix 14 ноября 2016 в 12:15

Отсюда получаем код
https://packagist.drupal-composer.org/

отсюда и обновляем

Практика будет лучше любых теорий)
поэкспериментируйте.
Установите ядро из ветки 8.1 и модуль какой-нибудь, тоже старой ветки.
Потом обновите до актуальных 8.2(или 3).
Вывод в консоли снимет массу вопросов.

Аватар пользователя multpix multpix 14 ноября 2016 в 12:31

Да вроде как людям понятны эти 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
Аватар пользователя multpix multpix 14 ноября 2016 в 12:49

фломастеры)

upd:
хотя, возможно, с точки зрения человекочитаемости файловой структуры,
sites - это место для мультисайтинга, и разделения модулей специфичных для отдельных проектов,
а modules и themes в корневой - для одного проекта.

ох и долго же еще друпалу до Drupal on Rails)))

Аватар пользователя gun_dose gun_dose 14 ноября 2016 в 12:56

Никогда не известна наперёд дальнейшая судьба проекта. Вдруг через N лет дороги разработчика и заказчика окончательно разойдутся, выйдет критическая обновка, а заказчик захочет вручную обновить ядро. И тогда прощай весь кастомный код, если он не в sites.

Аватар пользователя multpix multpix 14 ноября 2016 в 13:08

Почему?
сотрутся modules/custom/* и themes/custom/* ?
и что-то произойдет с git репозиторием?

Как по мне - описанный метод как раз и позволяет избежать подобных казусов))))

Аватар пользователя gun_dose gun_dose 14 ноября 2016 в 13:15

Объясняю ситуацию:
2028 год. Сайт достался по наследству внукам заказчика. Вы решили поставить автоочистку своих репозиториев, в которых 10 и более лет не было никаких изменений. Сайт всё это время исправно работал. Но наступает очередной друпалгедон. Внуки заказчика думают, что надо бы обновить сайт. Контакты разраба остались в скайпе их деда, который завещал пароль внучке, которая с внуками не в ладах. Поэтому новоиспечённые хозяева сайта решают обновить по первой попавшейся инструкции из интернета, где написано "Удалите из корня сайта всё, кроме папки sites". Естественно папки modules, themes и .git отправятся на кладбище удалённых файлов. Далее последует паника, ругань, драки, и, возможно, даже слёзы. А всё потому, что кто-то решил не следовать общепринятоым правилам.

Аватар пользователя multpix multpix 14 ноября 2016 в 13:46

ого, сразу видно - не бодыль.
спасибо конечно, но я сегодня не буду, мне еще работать
)))

но ты побереги себя - хороших собеседников - по пальцам пересчитать.

Аватар пользователя gun_dose gun_dose 14 ноября 2016 в 13:36

Но ведь не просто так придумали структуру, что бесчинствовать можно только в sites, а остальное - священное ядро

Аватар пользователя multpix multpix 14 ноября 2016 в 14:00

Я попробую перевести это на русский.

Создавая свой код, привлекая код других людей,
вы должны дать себе ответ на следующие вопросы:
привлеченный в ваше приложение сторонний код - это ваш код или нет,
если не вы сопровождаете код - где его хранить и как собирать.

хранить, собирать
сейчас в php проектах для этого применяются два инструмента:
git и composer.

Аватар пользователя gun_dose gun_dose 14 ноября 2016 в 14:13

Мне тоже нравится этот подход, но я пока как кэлх тупо храню в гите весь сайт, кроме files.

Что касается фломастеров, я всё же настаиваю, что кастомный и контрибный код должен быть в sites. Потому что если он там, то обновить ядро сможет любой колхозник за 10 минут.

С другой стороны, чего париться о проблемах заказчика, который перестал с тобой сотрудничать?)))

Аватар пользователя Grenuy Grenuy 3 мая 2017 в 22:32

КАК КАЧНУТЬ ПАПКУ CORE???
пытаюсь перейти на трушный метод разработки, и с drupal 7 на drupal 8
собственно первое что привлекает это как раз возможность работать с гитом.
так вот ВОПРОС знатоки!
Поставил все через композер, инстальнул возможно даже добавил модли

composer create-project drupal/drupal dir 8.*@stable
drush site-install --db-url=mysql://{username}:{password}@Localhost/{database}
composer require drupal/token @stable
drush en token

все классно! далее гитнул это все дело, и перехожу на другой сервер(к примеру с локального на дев сервер)
Вот сделал

git clone repo
composer install

И папки core нет уже и там подпилял, и там, и то попробовал и се, а папки нет, как сделать через cli что бы она появилась?

Аватар пользователя multpix multpix 4 мая 2017 в 0:00

тут в статье используется шаблон https://github.com/drupal-composer/drupal-project
не помешает изучить его док.
в корне созданного проекта делаем composer install
а то, что привыкли называть drupal root - это в кат. web, туда заходим только чтоб подрашить)

Аватар пользователя Grenuy Grenuy 4 мая 2017 в 8:18

С установкой через композер проблем нет. Вопрос именно переноса проекта с одной машины на другую посредством git+composer использовая gitignore core сидит там, и при розворачивания по мануалу не подтягивается.

Аватар пользователя multpix multpix 4 мая 2017 в 9:07

@Grenuy

в систему контроля версий - весь проект:

PROJECT_NAME
├── .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

Дале:

git clone REMOTE_REPO/PROJECT_NAME
cd PROJECT_NAME
composer install
Аватар пользователя Grenuy Grenuy 4 мая 2017 в 8:46

gitignore имеет

# Ignore core and vendor when managing dependencies with Composer.
core
vendor

вот вендер роворачиваеться, а core все никак... ( да и по логики должно было бы подтянуться, ведь везде одинаковый и с репы должно тянуться, да и что бы по трушному делать... Вот и ищу где что сделал не так, или чудо команду которая на новой машине, с которой подтянул проект с гита, что бы еще и подтянулся core

Аватар пользователя Grenuy Grenuy 4 мая 2017 в 9:14

install на локальную машину

composer create-project drupal/drupal . 8.*@stable

добавляем для теста несколько модулей

composer require drupal/token @stable
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

# Ignore files generated by PhpStorm
.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 add .
git commit -m "Bla bla"
git push

Устанавливать пока не обязательно, позже буду, хотя бы движок развернуть что бы работало

далее уже в новой папке

git clone MyRepo .
composer install

все... вендор появился, модуля так же, core нет.

Аватар пользователя multpix multpix 4 мая 2017 в 9:24
composer create-project drupal-composer/drupal-project:~8.3 PROJECT_NAME
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

откуда то еще

git clone REMOTE_REPO/PROJECT_NAME
cd PROJECT_NAME
composer install

Распространяем весь проект, в его корне работаем с composer
(не в web, в котором друпал и куда нацелен вебсервер)

#PROJECT_NAME/.gitignore

# 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/

Аватар пользователя Grenuy Grenuy 4 мая 2017 в 9:57

С этим работает
composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
А вот с офф не работает
composer create-project drupal/drupal dir 8.*@stable

Жаль.. Будем пока жить не с официальным Smile спасибо!

Аватар пользователя vinta vinta 22 мая 2017 в 9:37

Помогите дилетанту, как заставить испонятся команды с помощью 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 в корне, открывал этоу папку, там какие то ссылки, файлов нет, и я не знаю как это использовать, короче помогите, как заставить работать драш и друпал консоль

Аватар пользователя multpix multpix 22 мая 2017 в 10:33
1

Если есть надобность использовать 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/ - для его оперативной работы, там нет исполняемых.

Аватар пользователя vinta vinta 22 мая 2017 в 13:17

С друпал консолью разобрался, спасибо. С драшем не до конца. Я установил версию друпала с друпал комерцем возможно в этой версии драша в комплекте нет, в composer.json о нём упоминается только в строках

 "extra": { "drush/contrib/{$name}": [
                "type:drupal-drush"
            ]
        }

Особой нужды в драш у меня нет, но всё таки хочется знать, как его установить, надо редактировать composer.json или устанавливать через командную строку

Аватар пользователя vinta vinta 27 мая 2017 в 7:32

А способ установки дополнительных модулей через композер, например:
composer require drupal/token @stable
лучше чем добавление модулей дедовским методом через админ панель сайта?
Просто мне легче по старинке, я не очень дружу с командной строкой. Есть ли разница с точки зрения функционирования сайта?

Аватар пользователя gun_dose gun_dose 27 мая 2017 в 8:02
2

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

Аватар пользователя vinta vinta 28 мая 2017 в 7:20
А с версионированием Вы дружите?
Одно дело дело держать в репозитории весь код друпала и контрибных модулей и совершенно другое - один единственный конфигурационный файл композера.

Нет, не понимаю о чём Вы говорите. Догадываюсь что речь идёт о git. Изучаю его сейчас, смотрю курсы от lynda. И какой репозиторий? Свой собственный на своём хостинге или какой нибудь общак? И зачем это, имея конфигурационный файл композера можно восстановить сайт при его падении?

Аватар пользователя multpix multpix 28 мая 2017 в 10:14
1

Не надо путаться)

Вы используете шаблон организации проекта на базе 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% случаев упасть им помогают их разработчики)
Это не решает вопросы бекапа контента.
Это автоматизирует процесс разработки и обслуживания проекта.

Аватар пользователя vinta vinta 28 мая 2017 в 13:21

А правильно ли я понял, если у меня установлен какой нибудь модуль и вышла его новая версия, и я хочу его обновить, то надо просто выполнить команду
composer update
даже не указывая какой модуль, композер сам его найдёт и обновит?

Аватар пользователя bumble bumble 28 мая 2017 в 13:26

Композер обновит только код.
Все обновления (/update.php и дочерние зависимости) так и остаются на плечах разработчика.

Аватар пользователя multpix multpix 28 мая 2017 в 13:49

Ааа) главное не фигачить так в продакшене)))

В среде разработки - доводить до рабочерго а потом тем-же гитом на сервак и собирать уже проверенное.

Аватар пользователя multpix multpix 28 мая 2017 в 13:39
1

В принципе - да.

Это обновит весь список,
но можно указывать и конкретную цель.
https://github.com/drupal-composer/drupal-project#updating-drupal-core

В composer.lock заглянуть - там полный список того что уже есть.
(править его не нужно - создается автоматом)

Но, однозначно - эта статейка и ветка обсуждений, это только старт.
Полюбому вникать нужно самостоятельно.
Очень обширный материал.

Я на всяк случай ссылки полезные в конце перевода собираю,
Если найдешь чего интересного, кидай в коменты, разберем.

Аватар пользователя vinta vinta 28 мая 2017 в 14:33

То есть если я захочу конкретно обновить модуль token, надо писать
composer update drupal/token
а ещё лучше:
composer update drupal/token --with-dependencies
?
Немного насчёт update.рhp
Как я упоминал ранее, есть сборка друпал комерца для установки через композер, и в документации по обновлению самого комерца написано, что лучше чем update.рhp выполнять команды друпал консоли

drupal update:debug
drupal update:execute

уж не знаю хорошо это или плохо, но вот они пишут так.

Аватар пользователя multpix multpix 28 мая 2017 в 14:45

https://github.com/drupalcommerce/project-base - это шаблон
структура проекта которую он создает очень отличается от того, что получаем с дефолтным коробочным компосером.
если пользуешься шаблоном - читай док к шаблону)

Аватар пользователя vlucas vlucas 2 июня 2017 в 14:55

Может не по теме, но очень близко:

Имею:
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, а тут ещё рекомендуют выносить папку с конфигами на уровень выще папки сайта? Как это всё собрать воедино? )))

Может кто что-нибудь посоветует?

Аватар пользователя multpix multpix 2 июня 2017 в 15:48

Василий Сергеевич wrote:

Как это всё собрать воедино

Воплне себе реализуемо и даже удобно.

Сам думал о том-же: каталог с конфигами для 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 нашего проекта.
Все.

Аватар пользователя vlucas vlucas 2 июня 2017 в 16:02

Для меня сейчас непонятен момент с пользователями.
Я не очень силен в linux...
Если вынести папки ядра из директории пользователей, необходимо будет завести пользователя под эти нужды, не от root же обновлять потом? И не будет ли проблем с доступом к ним?

Аватар пользователя multpix multpix 2 июня 2017 в 16:30

это уже вопросы организации кода на продакшн

как вам такой вариант:
для работы с кодом сайтов - один пользователь deployer
в его дом каталоге сайты, на них нацелен вебсервер
владелец файлов - deployer, вебсервер добавлен в группу
(http://help.ubuntu.ru/wiki/стандартные_права_unix)
каждый сайт - полный пак всех необходимых файлов со всей структурой каталогов
переносить (между машиной разработчика, хранилищем кода, тестовыми стендами, производственным сервером) с git толко свой код,
сторонний собирать уже на месте композитором (это можно автоматизировать теми-же хуками https://git-scm.com/book/ru/v1/Настройка-Git-Перехватчики-в-Git).
и только обслуживать вебсервер - с админ правами (добавить сайт, перезапустить и пр.)

еще может будет полезным узнать о таком подходе:
http://drupal.ru/node/131184

как будет время про CI еще наваяю - мне эта тема самому интересна.

Аватар пользователя vlucas vlucas 2 июня 2017 в 16:41

multpix wrote:
для работы с кодом сайтов - один пользователь deployer
в его дом каталоге сайты, на них нацелен вебсервер

Мне необходимо, чтобы владельцами сайтов были разные пользователи!
Считаю, что это и по безопасности правильно, тем более, если владельцы сайтов - разные.

multpix wrote:
сторонний собирать уже на месте композитором

Ну разработа то на локале вся ведется, там тоже же ядро и контриб обновлять надо!

Аватар пользователя vlucas vlucas 2 июня 2017 в 16:28

Т.е., если правильно понял, можно совместить 2 рецепта (в этой статье и в http://drupal.ru/node/130460).
и

multpix wrote:

Для вебсервера корневым указываем каталог web нашего проекта.

Git в таком случае будет отвечать только за кастом и конфиги а за ядро и контриб - composer.

А как добиться, чтобы ядра и контриба вообще в проекте не было, ну т.е. чтобы они лежали отдельно а в проекте только ссылки на них были. Такое возможно?

Аватар пользователя multpix multpix 2 июня 2017 в 16:35

возможно то все, но надо ли)))

мы ведь так просто получаем этот код в проект - одна команда и вуаля - все на месте.

Аватар пользователя vlucas vlucas 2 июня 2017 в 16:42

multpix wrote:
возможно то все, но надо ли)))
мы ведь так просто получаем этот код в проект - одна команда и вуаля - все на месте.

А обновлять потом ядра каждого сайта в отдельности?
А так можно было бы один раз обновить всё сразу!

Аватар пользователя bsyomov bsyomov 3 июня 2017 в 21:51
1

Безусловно обновлять(и хранить), ядро и модули для каждого проекта надо отдельно.
Есть очень не нулевой шанс, что вам понадобятся, например, разные мажорные версии модулей для разных проектов.

Аватар пользователя bsyomov bsyomov 5 июня 2017 в 21:04
1

Апдейт ядра может что-то у вас сломать. Это не уникальная ситуация, такое бывало и в 6 и в 7 ветке.
И вполне, может возникнуть необходимость, на одном сайте, апдейт ядра накатить, а не другом, решить проблему, или дождаться апдейта какого-нибудь модуля, и только потом накатить.

Ничего хорошего, в одном ядре для пачки сайтов нет. Место - это экономия на спичках. А проблем в поддержке покинуть такая экономия может в полный рост.

Аватар пользователя vlucas vlucas 2 июня 2017 в 16:48

Quote:

Не используйте матерные или агрессивные слова )))

Вы можете использовать хуки того же GIt и по git pull делать composer update


Я подозреваю, что это займет больше времени.
Да и место на диске занимать один и тот же код будет.
Может можно как-то симлинками организовать?

Аватар пользователя multpix multpix 2 июня 2017 в 17:10

и тут на помошь придет друпал

если хотите избежать дублирования кода - используйте мультисайтинг
но у вас следующий вопрос возникнет - два пользователя...
ответ - два мультисайтинга)
возможно спросите - так у каждого же по одному сайту...
ответ - тогда зачем такие сложности)))

но попробуйте использовать ссылки,
тут вам нужно будет основательно переработать этот шаблон, если хотите имено его использовать так,
настоятельно рекомендую пробовать не на продакшен,
и помимо помощи форума - проработать этот вопрос со своим сисадмином.
а с результатами - это ведь будет хорошая тема для публикации в ваш блог здесь)))

Аватар пользователя Grenuy Grenuy 5 июня 2017 в 10:19

Еще вопросик, вот я начал делать сайт, куча модулей подключил все хорошо, в гит за пушил, все отлично, колега с гита пулыть, розворачивает, и тут вопрос, как можно автоматично включать\выключать модуля, и передавать эту инффу в гит(я знаю что можно через DRUSH en\dis но как сделать что бы какие именно модуля включились выклчюились в гит передать?
)

Аватар пользователя gun_dose gun_dose 5 июня 2017 в 10:26

На восьмёрке для этого достаточно сделать экспорт и импорт конфигурации. Т.е. перед пушем, вернее перед git add запускать drush cex, а сразу после пулла запускать drush cim

Аватар пользователя multpix multpix 5 июня 2017 в 10:28

активция и настройки какого-то модуля - это настройки которые хранятся в БД
в 8-ке их можно описывать с помощью конфигов
(т.е. выносим описание конфигурации в файл, который можем хранить в системе контроля версий)
подробней про конфиги здесь: http://drupal.ru/node/130460

Аватар пользователя Grenuy Grenuy 5 июня 2017 в 11:58

То как пробывал, все настройки хорошо летают, но отключения\включения модулей приходиться доп. командами DRUSH (настройки этих модулей норм синкаються через гит)

Аватар пользователя vlucas vlucas 5 июня 2017 в 21:11

bsyomov wrote:

Апдейт ядра может что-то у вас сломать. Это не уникальная ситуация, такое бывало и в 6 и в 7 ветке.

И вполне, может возникнуть необходимость, на одном сайте, апдейт ядра накатить, а не другом, решить проблему, или дождаться апдейта какого-нибудь модуля, и только потом накатить.
Ничего хорошего, в одном ядре для пачки сайтов нет. Место - это экономия на спичках. А проблем в поддержке покинуть такая экономия может в полный рост.


Ну, даже не знаю, что написать. Сколько работаю - не было у меня подобных ситуаций, слава Богу.
Но даже если и будет, то что помешает,для какого-то одного, конкретного сайта своё-нужное ядро положить?

Аватар пользователя multpix multpix 5 июня 2017 в 21:53

как принцип,
у самодостаточного изолированного проекта - все же больше плюсов чем минусов.

в тех же рельсах - гемы не лежат в проекте, но мы можем указывать для конкретного проекта специфические версии,
использовать тот-же rvm, делать гемсеты, и это снимает массу проблем.

в вашем случае - нужно исходить из задачи,
если есть необходимость мониторить и управлять роем друпалбасед сайтов - стоит подумать о какой то внешней системе администрирования и мониторинга.

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

разумеется, это всего-лишь мое скромное мнение))

Аватар пользователя fairrandir fairrandir 5 июня 2017 в 22:26

Василий Сергеевич wrote:

Сколько работаю - не было у меня подобных ситуаций, слава Богу.

А мне вот например версия 7.39 нет-нет, да и приснится в кошмаре.

Аватар пользователя bsyomov bsyomov 6 июня 2017 в 17:13

Это просто говорит о том, что вам повезло, или вы не своевременно обновлялись. Smile

Лучше использовать сразу хороший подход, а не придумывать костыль в процессе решения проблемы.
Никакого реального смысла и пользы в использовании одного ядра/модулей для разных проектов просто нет. А минусы есть.

Аватар пользователя Egmont Egmont 11 июня 2017 в 22:06

Вот только, 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. Обучающие материалы и не только
Автор Олег Кот. После чего всего, я понял, что я попал не в хорошую компанию. Я ведь просто как юзер, загрузил сайт.
Да, драш, проходил, не нужен он точно теперь. Инструментов предостаточно других.

Аватар пользователя vlucas vlucas 6 сентября 2017 в 14:25

Подскажите как быть с библиотеками, например, модуля colorbox, как делать чтобы композер их тоже подгружал?

Аватар пользователя bumble bumble 6 сентября 2017 в 14:50

Композер, все же, менеджер PHP-пакетов. Но, не удивлюсь если есть инструменты для интеграции и других зависимостей.
А также, не стоит забывать о директиве scripts.

Colorbox - JS (Jquery) библиотека. Ее можно контролировать с помощью специализированных pm (npm, bower). И это уже, скорее, дела фронтендерские.

Также, если речь идет именно о модулях Drupal, большинство разработчиков предусматривают возможность загрузки библиотек с помощью Drush. Например для Colorbox, библиотеку можно загрузить командой
drush colorbox-plugin

Для других - читайте документацию к модулю.

Аватар пользователя bumble bumble 6 сентября 2017 в 15:22

Ну, это на свой страх и риск.
Можно только надеяться что автор пакета будет держать в репозитории актуальную библиотеку.

Ну, и это скорее костыль, чем решение, т.к. убивает саму идею контроля пакетов. Лучше уж так.

Аватар пользователя bumble bumble 6 сентября 2017 в 21:05
1

Я не про риск использования "чужих" пакетов, а про риск получения не актуальной библиотеки.

  • Неправильный подход: форкнуть чужую библиотеку, добавить composer.json, зарелизить в packagist.
  • Правильный подход: использовать предоставляемые композером возможности, получать оригинальную библиотеку и контролировать ее версию.
Аватар пользователя Kaylang Kaylang 11 января 2018 в 15:34

Доброго всем времени суток!
Извиняюсь за ньюбский вопрос.

Есть:
ОС Ubuntu с Apache 2.4
В системе работаю под своим юзером.
Сайт Drupal 8 установлен композером в директорию /var/www/мой сайт. Установка производилась от своего юзера, после чего, для корректной работы сайта права на директорию переопределены юзеру www-data.

При попытке установить дополнительный модуль композером, получаю сообщение "web/modules/contrib/дополнительный_модуль does not exist and could not be created." т.к. у текущего юзера нет прав на директорию.
И что делать? Каждый раз при установке модуля переопределять права на директрорию или есть какие-то другие варианты?

Или я что-то не понимаю?

Аватар пользователя Kaylang Kaylang 11 января 2018 в 16:21

Quote:

usermod -a -G www-data $USER

Премного благодарен! Линукс тоже ещё осваиваю, упустил из виду возможность добавления юзера в группу.