15 октября 2016 в 1:41
Проблема.
Неоднократно замечал, что те, кто часто просит здесь поддержки, бояться что-либо сломать в своих сборках, опасаются экспериментов из-за опасения потерять существующие наработки; или, испытывая сложности с переносом конфигураций между сайтами - попросту берут, да и работают на продакшн.
Решение.
Не нужно трогать продакшн сервер, не нужно заморачиваться с дампами БД ради переноса конфигурации,
все намного проще.
В Drupal8 проще - появилась система управления конфигурациями, Configuration Management.
Работая с Drupal8-сайтом, возникает необходимость сохранять и переносить следующее:
Конфигурации, Контент, Сессии, Состояния.
Короткий разговор пойдет именно о переносе конфигураций.
Конфигурация, это настройки сайта: название и слоган, активная тема, активные модули, типы материалов и поля, вьюсы, и прочие настройки.
Грубо говоря то, что "накликано" )))
Хранение настроек в БД - полохо.
Хорошо то, что Drupal8 может хранить множество своих настроек в .yaml файлах.
Инструменты для работы с конфигурациями - модуль configure из ядра Drupal 8 (имеющий ui) и drush.
Прошу рассмотреть пример работы над проектом work_with_conf с использованием drush.
Создадим каталог для проекта, содержащий каталог для хранения своих конфигураций,
загрузим свежий drupal:
mkdir -p work_with_conf/config && cd work_with_conf && drush dl drupal
Получили следующую структуру:
├── config
└── drupal-8.2.1
├── autoload.php
├── composer.json
├── composer.lock
├── core
├── example.gitignore
├── index.php
├── LICENSE.txt
├── modules
├── profiles
├── README.txt
├── robots.txt
├── sites
├── themes
├── update.php
├── vendor
└── web.config
Инсталлируем drupal-сайт,
активируем модуль config,
сделаем попроще пароль (не делайте так в продакшн),
подкорректируем права для внесения изменений в файлы,
скопируем из примера файл локальных настроек:
Отредактируем settings.php и settings.local.php файлы следующим образом:
# Эта конструкция позволит нам использовать файл локальных настроек, в продакшн это лишнее
# Достаточно просто снять комментарий с этих строк
#
if (file_exists(__DIR__ . '/settings.local.php')) {
include __DIR__ . '/settings.local.php';
};
#
# При установке сайта, создается следующая строка,
# определяющая путь к каталогу sync
# тут имеет смысл хранить конфигурации, когда сайт в продакшн
#
$config_directories['sync'] = 'sites/default/files/config_ХЕШ_СТРОКА/sync';
# Так мы указали каталоги, в которые будем сохранять свои конфигурации
#
$config_directories = array(
'active' => '../config/active',
'staging' => '../config/staging'
);
Восстановим нужные права для файлов и каталогов:
chmod 0555 sites/default && chmod 0444 sites/default/settings.php
Теперь мы можем это использовать.
В случае продакшн, мы синхронизируем настройки из sync каталога
При локальной разработки мы оперируем active и staging каталогами.
В active мы храним то, к чему в случае чего хотим вернуться.
В staging мы храним нашу работу
Пример использования:
#
drush rs
# Экспортируем изначальное состояние в active
#
drush config-export active
# Активируем тему, к примеру Bartik
# Добавим тип материала foo
# Изменим имя сайта, слоган, добавим вьюс...
# Экспортируем измененное состояние в staging
#
drush config-export staging
# Вернемся к варианту active
#
drush config-import active
# в выводе наблюдаем - какие настройки будут добавлены, удалены или обновлены,
# примерно так:
Collection Config Operation
core.extension update
system.theme update
block.block.bartik_login delete
block.block.bartik_tools delete
block.block.bartik_admin delete
block.block.bartik_branding delete
block.block.bartik_messages delete
block.block.bartik_page_title delete
block.block.bartik_local_tasks delete
block.block.bartik_local_actions delete
Import the listed configuration changes? (y/n):
# Вернемся к варианту staging
#
drush config-import staging
На этом пример завершен.
Возможности drush config не ограничиваются рассмотренными,
подробная информация в документации:
https://drushcommands.com/drush-8x/config/
прошу сразу обратить ваше внимание на аргумент --partial для экспорта/импорта.
P.S
хотя у модуля config и есть отличный ui,
я надеюсь, что приведенные мною примеры, как минимум пробудят интерес к drush у тех, кто его еще не использует.
и как само собой разумеющееся:
код храним в git, который не стесняемся изучать.
Всем добра 
Комментарии
Спасибо большое за информацию, нужен ещё без-консольный вариант.
Ну я вот, одного человека знаю кто пилит сайты на Восьмёрке на продажу. Это же жуть какая для разработчика и клиента. Чем же Семёрка то не устраивает?
Привет Костян)
"безконсольный вариант" это по адресу admin/config/development/configuration
если тема интересна: ISBN 978-1-78398-520-3 | Drupal 8 Configuration Management
И дело тут не в том, что меня устраивает - просто составил небольшой ман, чтоб было куда отсылать, если что)))
Примерно вот так:
установили
export PHP_EXEMPL="foo"
получили
<?php
echo 'PHP_EXEMPL: ' . $GLOBALS['_SERVER']['PHP_EXEMPL'] . "\n";
?>
А по configам:
там по умолчанию один sync (в settings.php его настройки), и соответственно вызывать:
drush config-export sync
Но мы при желании можем наклепать любые (хотя вполне хватает одного - два удобно для роллбэка)
(как пример active и staging - просто эти имена в оф.доках мелькают и константы у дру есть такие).
Пример экспорта configа:
langcode: en
status: true
dependencies:
module:
- system
theme:
- seven
id: breadcrumbs
theme: seven
region: breadcrumb
weight: 0
provider: null
plugin: system_breadcrumb_block
settings:
id: system_breadcrumb_block
label: Breadcrumbs
provider: system
label_display: '0'
visibility: { }
Заинсталили Дру
Сделали экспорт в active (у каждого configа uuid)
Чего-то нащелкали - самим не понравилось - импорт из active, и все как было
Чего-то нащелкали - надо показать - экспорт в staging - и показали
Устраивает - на продакшн импорт из staging и экспорт в active - конец итерации разработки и по новой))
Получается, что одна инсталляция дру как-бы эволюционирует от итерации до итерации.
При каждом импорте - сравнивает новое с предыдущим - на каждый чих - config, а у configа уникальный id.
Для одиночных configов удобно сделать каталог single и тут нужен флаг --partial
иначе один config применит, а остальные удалит)))
Сравнивает, и выводит что обновляем, что новое создаем, а что удаляем.
Главно - перед первым экспортом drush en config
И никаких ключей -y
Лучше лишний раз почитать что сейчас произойдет)))
Система - ниппель, но уж лучше так чем никак)))
Хотя, если пачку configов в гит хранить и на каждый экспорт active вешать тег - будет полная история проекта,
а staging можно по тематическим веткам использовать.
Вобщем как-т так))
С рельсовыми миграциями это и рядом не лежало.
P/S
Это ППц
Фильт "мат слов" реагирует на никнейм))))
Пользуем эту либу для фильтрации ругательств.
Сорри, твой ник она никак не пропустит... ))
На главной
ребята, а что там с pre-commit из .git/hooks
например так
exec echo "y" | drush config-export
exec git add /var/www/drupalvm/drupal/web/sites/default/sync/*
и в post-merge
exec echo "y" | drush config-import
exec drush cr
вроде как еще в settings.php нужно указать путь к папке sync
$config_directories['sync'] = 'sites/default/sync';
получил проект с таким конфигом, может кто-то может чуть подразжевать
насколько я понял при коммите, происходит импорт и добавление конфига в коммит
дальше при мерже с мастером например, конфиг накатится из папки sync
верно? в живую пока еще не тестил
Верно. Только конструкция
exec echo "y" | drush config-exportвыглядит странно. Флаг-yотменили?в папке sync yml файлы лежат, да и при коммите пишет кучу всего, видимо работает
Это ж пайп - отправили Йес на вход последующей команде.
Вроде все верно, перед коммитом экспорт всех конфигов и добавление их в коммит,
после слияния - импорт из конфигов.
Дык,
если -y не отменили в 8ке
хорошо когда вариантов больше чем один))
В свете этого https://www.drupal.org/project/drupal/issues/2980712 уже не совсем верная схема.