Перейти к основному содержанию
menu

Одна из наиболее интересных и полезных функций Drupal 8 - это его новая встроенная система управления конфигурацией. При разработке сайта на Drupal вы неизбежно столкнетесь с ситуациями, когда вам потребуется хранить и управлять параметрами конфигурации, такими как имя вашего сайта, параметры кэширования страниц, роли и параметры разрешений и т. д. Проблема возникает, когда вам нужно синхронизировать сохраненную конфигурацию между несколькими экземплярами одного и того же сайта Drupal, например, при наличии отдельных сред для разработки, подготовки и производства - что является предпочтительным рабочим процессом для обеспечения качества итогового продукта. Как Drupal 8 решает это требование? Управление конфигурацией приходит на помощь.

Вот что вы узнаете в этой главе:

  • Типы конфигурации в Друпале 8
  • API простой конфигурации
  • Конфигурация объектов
  • Схема конфигурации
  • Переопределение конфигурации

Давайте начнем с изучения того, что является конфигурацией, и рассмотрим типы конфигурации, используемые в Drupal 8.

Что такое конфигурация?


При разработке сайта на Drupal желательно выполнять работу по разработке в локальной среде, а затем перенести свой код в среду разработки на первом этапе для его тестирования. В ходе этого процесса вы, скорее всего, внесете изменения в некоторые элементы конфигурации, которые вы бы не захотели делать снова вручную. Почему так? Есть много веских причин.

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

Второй важный аргумент - это вероятность человеческой ошибки. Основываясь на приведенном выше примере, вы можете ясно увидеть, как легко совершить ошибку на любом из этих этапов в любой среде. Что если вы забудете создать поле в одном из созданных вами типов контента? Или если вы забыли назначить определенное разрешение одной из созданных вами ролей? Суть в том, что в итоге вы можете потерять функциональность, потому что сделали ошибку на одном из шагов.

И последнее, но не менее важное - это возможность обмениваться настройками конфигурации. Представьте себе ситуацию, когда вы работаете на сайте Drupal с 5 другими разработчиками. Каждый из разработчиков работает на своих локальных машинах, используя свои локальные базы данных для хранения данных. Теперь предположим, что вам поручено создать новый тип контента, который должен будет использовать каждый другой разработчик для создания некоторой функциональности. Будете ли вы бегать по офису и создавать этот тип контента на каждом компьютере разработчика вручную? Что делать, если вам нужно внести изменения в этот тип контента в будущем? Или написать электронное письмо разработчикам с просьбой внести эти изменения?

Вот тут-то и приходит управление конфигурацией. Эта новая система создана для выполнения требований по переносу настроек конфигурации между установками Drupal. Он предоставляет как API для работы с программным обеспечением, так и пользовательский интерфейс для импорта и экспорта конфигурации. В отличие от предыдущих версий Drupal, конфигурация теперь может храниться в экспортированных файлах в формате YAML. Эти файлы могут обновляться всякий раз, когда изменяется часть конфигурации, а затем могут быть перенесены на другие сайты Drupal, где они могут быть импортированы.

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

Типы конфигурации в Drupal


Система управления конфигурацией Drupal 8 определяет два основных типа конфигурации: Простая конфигурация и Объекты конфигурации. Мы рассмотрим оба в этом разделе.


Давайте начнем с простого типа конфигурации, иначе Simple Configuration API.

Простая настройка


Как следует из названия, этот тип конфигурации хранит простые настройки для модулей. Хорошим примером будет значение текстового поля, флажок в вашем модуле или имя вашего сайта Drupal, настроенного модулем System. Каждый набор конфигурации имеет свой собственный файл в файловой системе, предоставляя детальный способ управления параметрами конфигурации, которые принадлежат определенной части нашего сайта Drupal.

Определение конфигурации


Для примера из реальной жизни давайте рассмотрим некоторые файлы конфигурации, определенные модулем System. Во-первых, мы рассмотрим параметры конфигурации, хранящиеся в system.maintenance.yml в core / modules / system / config / install :

message: '@site is currently under maintenance. We should be back shortly. Thank you for your patience.'
langcode: en

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

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

Настройки конфигурации также могут быть вложенными, как в system.rss.yml:

channel:
  description: ''
items:
  limit: 10
  view_mode: rss
langcode: en

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

Чтение конфигурации


Simple Configuration API предоставляет простые в использовании удобные методы для работы с настройками конфигурации. Основываясь на нашем первом примере выше, вот как вы можете взаимодействовать с API и получать настройки режима обслуживания вашего сайта:

$config = \Drupal::config('system.maintenance');
$message = $config->get('message');

Этот фрагмент кода извлекает значение ключа сообщения из system.maintenance.yml .

Мы также узнали, что конфигурация может быть вложенной, что означает, что настройки могут быть определены с использованием отношения родитель-потомок. Чтобы прочитать вложенные параметры конфигурации в вашем модуле, вы можете разделить каждый уровень с помощью «.»: 

$limit = \Drupal::config('system.rss')->get('items.limit');

Мы можем прочитать настройки конфигурации на любом уровне определенного дерева конфигурации. Если под нашим текущим уровнем находится вложенная конфигурация, мы получим массив параметров конфигурации, возвращаемых Drupal, в соответствии со структурой параметров конфигурации, определенной в соответствующем файле YAML.

Также возможно получить все параметры конфигурации из файла вместо явного определения ключей. В этом случае мы бы вызвали метод get () без каких-либо параметров. 

$rss_configuration = \Drupal::config('system.rss')->get();

Приведенный выше код вернет ассоциативный массив параметров конфигурации, обозначенный именами соответствующих родительских записей конфигурации:

Array
(
    [channel] => Array
        (
            [description] => 
        )

    [items] => Array
        (
            [limit] => 10
            [view_mode] => rss
        )

    [langcode] => en
    [_core] => Array
        (
            [default_config_hash] => TlH7NNk46phfxu1mSUfwg1C0YqaGsUCeD4l9JQnQlDU
        )

)

Написание конфигурации


Мы также можем использовать API для программного изменения ранее определенных параметров конфигурации. Тем не менее, объекты конфигурации в Drupal являются неизменяемыми по умолчанию. Это сделано для предотвращения случайного переопределения параметров конфигурации. Если мы точно знаем, что делаем, и нам нужно переопределить конфигурацию, мы можем использовать  \ Drupal \ Core \ Config \ ConfigFactoryInterface :: getEditable (), чтобы получить изменяемую версию объекта конфигурации, в которой мы можем выполнять переопределения ,

Давайте попробуем это и переопределим некоторые настройки, определенные в system.rss.yml :

// Retrieve mutable configuration settings
$config = \Drupal::configFactory()->getEditable('system.rss');
// Set a scalar value.
$config->set('items.limit', 5);
// Set an array of values.
$channel_data = array('description' => t('Our really cool RSS feed.'));
$config->set('channel', $channel_data);
// Save the configuration object.
$config->save();
	
// Retrieve read-only configuration settings
$new_config = \Drupal::config('system.rss')->get();
	
print_r($new_config);

Давайте посмотрим, что мы здесь делаем. Во-первых, мы определяем объект $ config, который содержит изменяемые параметры конфигурации, полученные из \ Drupal :: configFactory () -> getEditable ('system.rss') . Мы используем эту переменную в последующих вызовах.

Затем мы используем set () метод для $ config объекта , чтобы установить items.limit настройку нашей конфигурации RSS, которая контролирует количество элементов , возвращаемых в RSS фиде сайта. Метод set () принимает два аргумента: имя (включая вложенные версии) элемента конфигурации, который мы хотим изменить, и значение, которое мы хотим установить.

// Set a scalar value.
$config->set('items.limit', 5);

На следующем шаге мы покажем, как мы можем передать массив параметров конфигурации методу set () . Мы создаем массив с ключом  description и устанавливаем его значение в "Наш действительно крутой канал RSS" . Затем мы передаем этот массив методу set (), который анализирует эту информацию и устанавливает соответствующий элемент конфигурации в системе на указанное нами значение. Это удобный способ изменения нескольких вложенных элементов конфигурации за один раз.

// Set an array of values.
$channel_data = array('description' => t('Our really cool RSS feed.'));
$config->set('channel', $channel_data);

Если бы элемент канала содержал дополнительные настраиваемые дочерние элементы, отличные от description , мы просто добавили бы их в массив $ channel_data , указав их соответствующие значения.

На последнем шаге мы сохраняем наши изменения конфигурации, вызывая $ config-> save () . Важно отметить, что этот метод необходимо вызывать , чтобы сохранить изменения конфигурации. Недостаточно вызывать метод set (), поскольку он не будет автоматически сохранять наши изменения, поэтому убедитесь, что вы всегда вызываете save () при изменении конфигурации.

Теперь давайте запустим этот код и рассмотрим результаты:

Array
(
    [channel] => Array
        (
            [description] => Our really cool RSS feed.
        )

    [items] => Array
        (
            [limit] => 5
            [view_mode] => rss
        )

    [langcode] => en
    [_core] => Array
        (
            [default_config_hash] => TlH7NNk46phfxu1mSUfwg1C0YqaGsUCeD4l9JQnQlDU
        )

)

Как вы можете видеть выше, наши изменения конфигурации были применены к настройкам [channel] [description] и [items] [limit] .

Метод setData ()


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

// Retrieve mutable configuration settings.
$config = \Drupal::configFactory()->getEditable('system.rss');
// Set all configuration settings.
$config->setData([
  'channel' => [
    'description' =>  t('Our even cooler RSS feed.')
  ],
  'items' =>  [
    'limit'	=>	8,
    'view_mode'	=>	'rss'
  ],
  'langcode'  => 'en'	  
]);
	
// Save the configuration object.
$config->save();
	
// Retrieve read-only configuration settings.
$new_config = \Drupal::config('system.rss')->get();
	
print_r($new_config);

Выполнение приведенного выше кода должно изменить параметры конфигурации system.rss , и мы должны получить вывод, подобный этому:

Array
(
    [channel] => Array
        (
            [description] => Our even cooler RSS feed.
        )

    [items] => Array
        (
            [limit] => 8
            [view_mode] => rss
        )

    [langcode] => en
)

Удаление конфигурации


Simple Configuration API также позволяет нам удалять параметры конфигурации из системы. В случае, если мы хотим сбросить конкретный параметр конфигурации, мы можем использовать метод clear (), предоставляемый API. Этот метод работает очень похоже на те, которые мы уже обсуждали:

// Retrieve mutable configuration settings.
$config = \Drupal::configFactory()->getEditable('system.rss');
// Clear the description of the RSS feed.
$config->clear('channel.description');	
// Save the configuration object.
$config->save();
	
// Retrieve read-only configuration settings.
$new_config = \Drupal::config('system.rss')->get();
	
print_r($new_config);

Как обычно, мы начинаем с извлечения изменяемых параметров конфигурации и сохранения их в переменной с именем $ config . Затем мы используем метод clear () , определяя ключ параметра, который мы хотим отменить, и затем вызываем метод save (), чтобы сохранить наши параметры конфигурации. Если бы мы должны были проверить возвращаемое значение $ channel_data  элемент будет пуст, потому что мы не задали ключ-значение в нашем фрагменте кода выше.

Array
(
    [channel] => Array
        (
        )

    [items] => Array
        (
            [limit] => 8
            [view_mode] => rss
        )

    [langcode] => en
)

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

Конфигурационные объекты


Объекты конфигурации - более сложный, но гораздо более гибкий способ хранения конфигурации. Их основная роль заключается в хранении данных конфигурации, которые обычно создаются вручную администраторами или вебмастерами. Несколько хороших примеров объектов конфигурации: типы контента, представления и блоки.

В следующей главе мы подробнее рассмотрим сущности в Drupal 8, поскольку это довольно сложная тема сама по себе. Но пока давайте рассмотрим тип объекта конфигурации, предоставляемый модулем «Блок», который позволяет нам экспортировать и импортировать конфигурации блоков.

Блок Сущность


Чтобы определить новый тип объекта конфигурации, вам необходимо расширить класс ConfigEntityBase и определить интерфейс, который расширяет ConfigEntityInterface . Это именно то, что можно увидеть в core / modules / block / src / Entity / Block.php :

namespace Drupal\block\Entity;

use Drupal\Core\Cache\Cache;
use Drupal\Core\Condition\ConditionPluginCollection;
use Drupal\Core\Config\Entity\ConfigEntityBase;
use Drupal\block\BlockPluginCollection;
use Drupal\block\BlockInterface;
use Drupal\Core\Config\Entity\ConfigEntityInterface;
use Drupal\Core\Entity\EntityWithPluginCollectionInterface;
use Drupal\Core\Entity\EntityStorageInterface;

/**
 * Defines a Block configuration entity class.
 *
 * @ConfigEntityType(
 *   id = "block",
 *   label = @Translation("Block"),
 *   handlers = {
 *     "access" = "Drupal\block\BlockAccessControlHandler",
 *     "view_builder" = "Drupal\block\BlockViewBuilder",
 *     "list_builder" = "Drupal\block\BlockListBuilder",
 *     "form" = {
 *       "default" = "Drupal\block\BlockForm",
 *       "delete" = "Drupal\block\Form\BlockDeleteForm"
 *     }
 *   },
 *   admin_permission = "administer blocks",
 *   entity_keys = {
 *     "id" = "id",
 *     "status" = "status"
 *   },
 *   links = {
 *     "delete-form" = "/admin/structure/block/manage/{block}/delete",
 *     "edit-form" = "/admin/structure/block/manage/{block}",
 *     "enable" = "/admin/structure/block/manage/{block}/enable",
 *     "disable" = "/admin/structure/block/manage/{block}/disable",
 *   },
 *   config_export = {
 *     "id",
 *     "theme",
 *     "region",
 *     "weight",
 *     "provider",
 *     "plugin",
 *     "settings",
 *     "visibility",
 *   },
 *   lookup_keys = {
 *     "theme"
 *   }
 * )
 */
class Block extends ConfigEntityBase implements BlockInterface, EntityWithPluginCollectionInterface {

@EntityType аннотации уже должны быть знакомы вам после нашего быстрого обзора плагинов в третьей части серии. Мы узнаем больше о синтаксисе аннотаций в следующей главе.


После определения его пространства имен, импорта различных требуемых пространств имен и определения типа сущности с использованием синтаксиса аннотации класса Block, определенный в этом файле, который расширяет класс ConfigEntityBase и реализует BlockInterface , который фактически является расширением ConfigEntityInterface .

Комбинация ConfigEntityBase , BlockInterface и  ConfigEntityInterface позволяет управлять конфигурацией блока с помощью системы управления конфигурацией. Объекты конфигурации гораздо более гибкие и более сложные. В следующей главе мы познакомимся с ними поближе, когда создадим наш собственный объект. Основное внимание в этой главе уделяется управлению конфигурацией в целом, и на данный момент вполне достаточно иметь общее представление.

Работа с файлами конфигурации


Расположение файлов конфигурации по умолчанию находится по адресу sites / default / files / config_ {hash} , где hash - это случайная уникальная строка, сгенерированная в процессе установки Drupal. Вы всегда можете узнать, какая у вас конфигурация по умолчанию, посмотрев в sites / default / settings.php следующую настройку:

$config_directories['sync']

Эта переменная создается Drupal в процессе установки. Именно сюда Drupal по умолчанию будет экспортировать ваши файлы конфигурации, когда вы это сделаете. Если вы посмотрите на папку, то увидите, что в имени папки есть довольно длинный хеш. Drupal создает эту случайную строку хеша для защиты наших файлов конфигурации в папке, делая невозможным подбор ее имени. Кроме того, он также создает  файлы .htaccess в папке, содержащей директивы, которые не позволяют Apache предоставлять эти файлы через Интернет.

В случае, если вы используете веб-сервер, отличный от Apache, обязательно защитите свои файлы конфигурации, чтобы они были доступны только соответствующим людям или системам.


По умолчанию папка, содержащая наши файлы конфигурации, пуста. Это потому, что мы еще не указывали Drupal экспортировать наши файлы конфигурации. Итак, давайте попробуем это сейчас.

Импорт, экспорт и синхронизация конфигурации


Система управления конфигурацией позволяет нам обмениваться конфигурациями между сайтами Drupal, только если они технически являются одним и тем же сайтом, что означает, что они являются копиями определенной установки. Как Drupal определяет это? При установке он создает UUID (универсальный уникальный идентификатор), который идентифицирует наш сайт:

uuid: 4053777c-e848-4676-ae04-053eea004f48

Передача файлов конфигурации будет работать только в том случае, если UUID целевой установки Drupal точно такой же. Это сделано по ряду причин, но основная идея заключается в том, чтобы мы не допустили ошибку, применив неподходящую конфигурацию к сайту Drupal случайно.

Чтобы настроить конфигурацию на своем сайте, перейдите к Конфигурация | Разработка | Синхронизация конфигурации . Этот раздел позволяет вам экспортировать, импортировать и синхронизировать конфигурацию между установками Drupal. Хотя мы не будем подробно останавливаться на пользовательском интерфейсе, мы продемонстрируем некоторые основные функции, которые вы можете использовать здесь.

Экспорт конфигурации


Пришло время начать экспорт некоторых параметров конфигурации. Давайте перейдем на вкладку « Экспорт », а затем нажмите « Один элемент» в области под-навигацией.

config

На этой странице вы можете экспортировать отдельные части конфигурации сайта Drupal. Экспорт таким образом создает текст в формате YAML, который можно скопировать и вставить на другой сайт Drupal. Давайте попробуем это!

Выберите Простая конфигурация в поле Тип конфигурации, а затем выберите system.rss в поле Имя конфигурации:

config

Затем Drupal заполняет параметры конфигурации с помощью вызова AJAX и вставляет его в текстовую область под полями выбора. Если вы следовали примерам кодирования в этой главе, ваш вывод должен выглядеть примерно так:

channel:
  description: 'Our even cooler RSS feed'
items:
  limit: 8
  view_mode: rss
langcode: en
_core:
  default_config_hash: TlH7NNk46phfxu1mSUfwg1C0YqaGsUCeD4l9JQnQlDU


Как мы уже узнали в этой главе, система управления конфигурацией автоматически обновляет объекты конфигурации при каждом их изменении в системе. И поскольку мы действительно изменили конфигурацию для system.rss , наши измененные настройки записываются в объект конфигурации.

Импорт конфигурации


Основываясь на предыдущем примере, мы можем взять экспортированный текст YAML и вставить его в нашу установку Drupal. Давайте попробуем это!

Чтобы правильно протестировать эту функцию, рекомендуется настроить клонированную установку сайта Drupal, над которым вы сейчас работаете (назовем его оригинальным сайтом ). Это означает, что вам нужно создать копию как кодовой базы, так и базы данных вашей текущей установки и настроить новый сайт (назовем его целевым сайтом ) в вашей среде разработки. Вы можете пропустить этот шаг и следовать, фактически не проверяя функциональность самостоятельно, если хотите. Тем не менее, понимание концепций и лучших практик будет намного проще, если вы будете делать то, что предлагается.
На целевом сайте Drupal перейдите в Конфигурация | Разработка | Синхронизация конфигурации  | Импорт | Отдельный элемент . 

На этой странице выберите Простая конфигурация в поле Тип конфигурации, введите system.rss в поле Имя конфигурации и вставьте экспортированную ранее конфигурацию (с исходного сайта) в текстовую область:

export

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

Синхронизация конфигурации


В некоторых случаях вы можете захотеть создать полный экспорт настроек вашей конфигурации. Этот экспорт будет содержать каждый объект конфигурации вашего сайта Drupal, экспортированный в соответствующие файлы YAML. Я собираюсь продемонстрировать, как это работает, но сначала, ради этой демонстрации, давайте изменим некоторые настройки конфигурации на нашем оригинальном сайте Drupal. Сейчас мы будем дорабатывать настройки RSS, поэтому давайте перейдем к Configuration | Веб-сервисы | Публикация и изменение  RSS Количество элементов в каждом фиде укажем до 15 и сохранение формы.

Далее перейдите в Конфигурация | Разработка | Синхронизация конфигурации  и нажмите  Экспорт . Вы должны перейти на страницу полного экспорта архива, которая позволяет вам создать полный экспорт конфигурации вашего сайта. Нажмите кнопку « Экспорт» , и ваш браузер должен загрузить архив, содержащий полную конфигурацию вашего сайта. 

Теперь, когда наш полный архив загружен, давайте перейдем на целевой сайт Drupal, куда мы импортируем этот архив. Перейти к  конфигурации | Развитие | Синхронизация конфигурации и нажмите вкладку Импорт . На странице «Полный архив» загрузим архив, загруженный на предыдущем шаге, и нажмите « Загрузить» . Если все прошло хорошо, мы должны увидеть следующее:

import

Экспортированный архив конфигурации загружается на целевой сайт, и Drupal обнаруживает, что есть разница между конфигурацией, которую мы импортировали, и тем, что мы в настоящее время имеем в базе данных. Это именно то , что мы ожидали , потому что, если вы помните, ранее мы изменили настройки RSS на оригинальном сайте и установить  количество элементов в каждом до 15 . 

Давайте нажмем кнопку «Просмотреть различия» и рассмотрим, что Drupal определяет как различия между активной конфигурацией сайта и загруженным архивом конфигурации:

dif

В фоновом режиме происходит то, что Drupal извлекает загруженный архив конфигурации и проверяет каждый объект конфигурации, один за другим, чтобы увидеть, есть ли какие-либо различия между содержимым файлов YAML и его локальной базой данных. Для нашей безопасности ни один из параметров конфигурации фактически не импортируется в этот момент. Вместо этого Drupal «ставит» эти параметры конфигурации и позволяет нам просмотреть переопределения, прежде чем мы дадим ему указание импортировать их. Этот дополнительный шаг позволяет нам быть уверенными в том, что мы импортируем на целевой сайт.

Мы можем закрыть этот мод и нажать « Импортировать все», чтобы начать процесс импорта. Drupal теперь будет анализировать и проверять все файлы YAML и импортировать их как объекты конфигурации. Наши исходные и целевые конфигурации сайтов Drupal теперь синхронизированы.

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

Управление конфигурацией с использованием контроля версий


Итак, мы увидели интерфейс управления конфигурацией в действии, но есть ли более удобный и надежный способ управления конфигурацией в Drupal? В конце концов, главная цель Системы управления конфигурациями - позволить нам экспортировать конфигурацию нашего сайта в статические файлы, отделенные от базы данных. Если мы сможем добиться этого, мы сможем управлять этими файлами, как и любым другим файлом в нашем проекте Drupal, например, классом PHP или файлом шаблона. Нет необходимости подчеркивать важность использования системы контроля версий при создании любого программного проекта, в том числе Drupal. Итак, давайте рассмотрим, как мы можем использовать VCS для управления конфигурацией Drupal.

Ранее мы видели, что в процессе установки Drupal создает папку по пути sites / default / files, которая будет содержать конфигурацию нашего сайта, экспортированную в файлы YAML. Проблема с  sites / default / files заключается в том, что это также корневая папка для всех общедоступных файлов Drupal, например, всех изображений, которые вы можете загрузить, всех агрегированных файлов CSS и JS, всех файлов PHP, проанализированных из шаблонов Twig и т. д. Рекомендуется, чтобы выбранный вами VCS игнорировал эту папку, потому что вы вряд ли захотите, чтобы эти файлы были включены в ваш репозиторий, либо потому, что они составляют часть содержимого вашего сайта (например, изображения), либо они динамически изменяются (например, агрегированный CSS). / JS файлы, шаблоны Twig и т. д.). Это означает, что нам понадобится другое местоположение для нашей папки конфигурации.

Типы каталогов конфигурации


Drupal позволяет нам создавать несколько типов каталогов конфигурации , указав их местоположение в переменной, которую мы видели ранее в этом посте,  $ config_directories в sites / default / settings.php . Все, что нам нужно сделать, чтобы добавить новый каталог, - это указать новый ключ массива со значением, установленным для папки в нашей файловой системе, относительно нашей установки Drupal. Давайте назовем этот каталог конфигурации 'version_control' и укажем его путь:

$config_directories['version_control'] = '../config/default';
Добавив эту строку в sites / default / settings.php, мы создали новый тип каталога конфигурации, который Drupal может использовать для экспорта конфигурации (и импорта конфигурации). Для дополнительной безопасности мы также указали, что эта папка должна находиться над нашим текущим рабочим каталогом, вне webroot. Это дополнительная мера, чтобы убедиться, что наша конфигурация не может быть доступна через Интернет.

Не забудьте добавить эту строку в каждый файл settings.php вашего сайта, для которого вы хотите, чтобы этот каталог конфигурации был доступен.
Итак, теперь мы добавили новый тип каталога конфигурации, но как нам его использовать? Drush приходит на помощь.

Управление конфигурацией с помощью командной строки


Если вы похожи на меня, вам нравится командная строка. Это намного быстрее, надежнее и веселее в использовании. Drupal имеет очень полезную утилиту командной строки , которая позволяет взаимодействовать с ним с помощью командной оболочки, называемой Drush ( Dru дружище shell). 

Мы не будем вдаваться в подробности Drush в этой главе, так как в интернете есть тонны информации. Официальную документацию и примеры можно найти по  адресу http://docs.drush.org/en/master/ .
Drush интегрируется с системой управления конфигурацией, чтобы предоставить нам удобные команды для экспорта и импорта конфигурации. Мы собираемся протестировать две его команды: drush cex (или config-export ) и drush cim (или config-import ).

Экспорт конфигурации с использованием Drush


Чтобы экспортировать конфигурацию с нашего исходного сайта Drupal с помощью Drush, откройте свой терминал и перейдите в ваш webroot. Затем введите следующую команду:

drush cex


Вам должно быть представлено следующее приглашение:

Choose a destination.
 [0]  :  Cancel          
 [1]  :  sync            
 [2]  :  version_control


Drupal обнаружил, что мы добавили каталог конфигурации, поэтому он спрашивает нас, в какую папку мы хотим экспортировать конфигурацию. Поскольку мы хотим управлять конфигурацией с помощью VCS, мы выберем вариант 2 здесь. Введите 2 и нажмите Enter . Вы должны увидеть следующий вывод:

Configuration successfully exported to ../config/default.


В фоновом режиме Drupal создал полный экспорт конфигурации нашего сайта и поместил соответствующие файлы YAML в указанную папку. Теперь вы можете фиксировать и помещать эти файлы в вашу любимую VCS и передавать их в расположение целевого сайта Drupal. Теперь мы готовы импортировать конфигурацию.

Импорт конфигурации с использованием Drush


Аналогично предыдущему шагу, используя ваш терминал cd в webroot вашего целевого сайта Drupal и введите следующую команду:

drush cim


Нам предлагается приглашение, которое уже должно быть знакомо:

Choose a source.
 [0]  :  Cancel          
 [1]  :  sync            
 [2]  :  version_control


Опять же, из-за каталога конфигурации, который мы настроили, Drupal хочет знать, из какой папки мы хотим импортировать конфигурацию. Мы снова выберем вариант 2  и нажмем Enter :

There are no changes to import.


Drupal сравнил активную конфигурацию целевого сайта с файлами YAML и пришел к выводу, что между ними нет никакой разницы. И это именно то, чего мы и ожидали, потому что ранее в этой главе мы синхронизировали конфигурацию между двумя сайтами. 

Мы, очевидно, хотим посмотреть и попробовать сами, как ведет себя Drush, когда происходят изменения в импорте, поэтому давайте вернемся к исходному сайту Drupal и изменим настройку конфигурации. Сейчас мы довольно знакомы со страницей настроек RSS; давайте перейдем к  конфигурации | Веб-сервисы | Публикация RSS , измените  количество элементов в каждом фиде на 10  и сохраните форму.

Теперь вернемся к терминалу и повторим шаг экспорта, как описано ранее:

drush cex
Choose a destination.
 [0]  :  Cancel          
 [1]  :  sync            
 [2]  :  version_control


Снова выберите вариант 2 и нажмите Enter . Вы должны увидеть другой вывод:

Differences of the active config to the export directory:

 Collection  Config      Operation                
             system.rss  update
The .yml files in your export directory (../config/default) will be deleted and replaced with the active config. (y/n): 


Вы можете видеть выше, что Drupal обнаружил, что есть различия между активной конфигурацией (база данных) и существующей экспортированной конфигурацией в нашей папке  ../config/default . Затем он просит нас подтвердить, что мы хотим обновить содержимое system.rss.yml с помощью новой конфигурации. Мы рады это сделать, поэтому ответим да.

Имейте в виду, что этот процесс заменит содержимое вашего существующего файла. Это означает, что если вы внесли изменения в любой из ваших экспортированных файлов конфигурации, они будут перезаписаны последующим процессом экспорта. Обязательно всегда используйте систему управления конфигурациями для экспорта и импорта вашей конфигурации.
Теперь давайте повторим процесс фиксации и отправки этого кода на целевой сайт Drupal. Затем перейдите в webroot и импортируйте конфигурацию. Мы собираемся немного изменить нашу команду импорта, чтобы Drush не предлагал нам указать каталог конфигурации:

drush cim version_control


Добавив имя каталога конфигурации в команду, мы дали команду Drush импортировать конфигурацию из version_control . Теперь вы должны увидеть следующий вывод:

 Collection  Config      Operation                
             system.rss  update
Import the listed configuration changes? (y/n): 


Как и ранее, Drupal обнаружил различия между активной конфигурацией целевого сайта и содержимым system.rss.yml и попросил нас подтвердить, что мы хотим импортировать конфигурацию из файла YAML. Отвечая 'y' на приглашение, мы должны увидеть следующий результат:

Import the listed configuration changes? (y/n): y
Synchronized configuration: update system.rss.                                                                                             [ok]
Finalizing configuration synchronization.                                                                                                  [ok]
The configuration was imported successfully.


Как видите, изменения конфигурации были импортированы, и процесс успешно завершен.

Резюме
В этой главе мы узнали о встроенной Системе управления конфигурациями Drupal, которая хранит параметры конфигурации в файлах YAML и предоставляет способы импорта, экспорта и синхронизации конфигурации между несколькими экземплярами сайта Drupal. Мы узнали о Simple Configuration API и его предоставленных методах для извлечения, переопределения и удаления настроек конфигурации. Мы также рассмотрели расширенные рабочие процессы для работы с конфигурацией с помощью командной строки и управления конфигурацией с помощью контроля версий.

assistant Теги

keyboard_arrow_up