Использование системы конфигурирования в Drupal 8

Заметка:

Информация в данной статье не отвечает действительности. Для уточнения текущего статуса и информации API Drupal 8 посетите официальное руководство.

Осмотр архитектуры.

Система конфигурирования применяется на трёх архитектурных уровнях.

1. Файловое хранилище

На самом нижнем уровне все конфигурационные данные сохраняются на диск в  подписанном сигнатурой файле XML формата в конфигурационной директории сайта В название конфигурационной директории входит случайно сгенерированный ключ.

Конфигурационные файлы должны выглядеть следующим образом. Файл prefix.example.xml

config:
 simple_int: 45
 str_var: "String variable"
 boolean_var: true

Организация файловой системы конфигурации обсуждается здесь. http://drupal.org/node/1479492. Ядро будет делать файлы по типу system.site_information.xml. Название конфигурационного файла отображает модуль ,кому принадлежит и флаг, который отображает специфику - filemodule.flag.xml.

Одно из преимуществ хранения конфигурационный данных файлах - Мы можем ограничить количество загружаемых данных на каждый запрос. Ядро Drupal 7 загружает все данные из таблици переменных в память при каждом запросе страницы.

2. Активное хранилище

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

В конфигурации по умолчанию, данные будут сохраняться в центральной таблице "config":

CREATE TABLE config (
 name varchar(255) NOT NULL DEFAULT '' COMMENT 'The identifier for the  configuration entry, such as module.example (the name of the file,  minus .xml).',
 data longtext NOT NULL COMMENT 'The raw XML data for this configuration entry.',
 PRIMARY KEY (name),
);

С первого взгляда структура похожа на таблицу "variables" в Drupal 7, фундаментальная разница заключается в том, что таблица хранит конфигурационные объекты. Как говорилось выше конфигурационная таблица не загружается полностью в память. Дополнительно обеспечивает разграничение конфигурационных файлов, которые требуют перегрузки(обновления), обеспечивает защиту от неправильного построения конфигурационных данных, вызывая ошибки сайта.

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

UI изменения (автоматично): когда нажата кнопка сохранить на странице администрирования, данные обновляются в активном хранилище.

Изменения кода (вручную): При миграции файлового хранилища с dev на prod, к примеру, Файлы будут заменены, но данных в базе данных нет. Данные будут продолжать приходить из активного хранилища,  пока администратор сайта не обновит данные с файлового хранилища в активное хранилище с помощью панели администрирования или утилиты drush. (Заметка: данный функционал до сих пор реализуется, следите за прогрессом развития: http://drupal.org/node/1447686)

3. API конфигурирования

На этом уровне рассмотрим функции ,с которыми разработчики модулей будут манипулировать значениями конфигурации ,в основном для замены функций variable_get()/variable_set().

// Загрузим конфигурацию из активного хранилища.
// 'prefix.name' ссылается на .xml файл, без расширения.
$config = config('prefix.name');
// Доступ к одной из переменных хранилища.
echo $config->get('my.value');
// Изменяем значение и сохраняем в активное хранилище и хранище в файловой системе.
$config->set('my.value','my new value');
$config->save();

Я Drupal разработчик. Как на меня повлияют эти изменения?

Определение собственных конфигурационных настроек проходило смешанно: системная форма настроек system_settings_form() магически сохраняло переменные конфигурации в таблицы переменных. Модуля Flag и Views  использовали шаблон - hook_X_default(). В новой системе определение собственных переменных конфигурирования происходит в фале xml, который находится в данном модуле. Эти файлы также будут существовать в конфигурационной  директории сайта, директории модуля. Вы определяете значение переменных но только в одном месте - в файле конфигурации в вашем модуле.

К примеру это может выглядеть так:

image.styles.thumbnail.xml:

 thumbnail

 

config:
 name: thumbnail
effects:
 image_scale:
   data:
     width: 100
     height: 100
     upscale: 1
   weight:0

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

В  Drupal 7 и ниже все переменные глобальны, получение и сохранение происходит следующим образом:

// Получаем название сайта.
$site_name = variable_get('site_name', 'Drupal');
// Изменяем название сайта на какое-нибудь другое.
variable_set('site_name', 'This is the dev site.');

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

// Загружаем набор данных, получаем название сайта.
$config = config('core.site_information');
$site_name = $config->get('site_name');
// Изменяем и сохраняем.
$config->set('site_name', 'My Awesome Site');
$config->save();

Миграция конфигурационных данных с dev на prod серверы.

В общем это будет выглядеть так:

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

Можете использовать различные diff утилиты для определения ,для нахождения изменений в настройках. Если всё выглядит так, как ожидалось, вы можете перенести настройки с dev на prod сервер вашим способом. Настройки сразу не будут приняты в активное хранилище. Для обновлений настроек в активном хранилище с файлового хранилища перейдите на страницу администрирования admin/configuration/system/config и обновите или выполните данную команду

drush config-update

(Замечание: финальное размещение/команда могут быть другими).