Перенос данных через features — добавляем новый компонент для экспорта

от автора

Недавно мне потребовалось перенести настройки модуля metatag с локального сервера на боевой. Для этого я хотел воспользоваться модулем features, но меня ждало разочарование — модуль metatag не поддерживает features API. Гугление ничего не дало, я нашел только несколько костылей вроде «сдампить таблицу metatags_config и выполнить запрос на боевом». Поэтому я решил разобраться, как можно добавить новую сущность для переноса через «фичи».

Я расскажу как это сделать на примере модуля metatag.
Сперва нужно реализовать хук features_api, в нем определяются компоненты для экспорта через «фичи».

/**
 * Implements hook_features_api().
 */

function metatag_features_api() {
  $components = array(
    ‘metatags’ => array(
      ‘name’ => t(‘metatags’),
      ‘features_source’ => TRUE,
      ‘default_hook’ => ‘metatag_export_default’,
      ‘default_file’ => FEATURES_DEFAULTS_INCLUDED,
      ‘file’ => drupal_get_path(‘module’, ‘metatag’) . ‘/metatag.features.inc’,
    ),
  );
  return $components;
}
 

Стоит обратить внимание на ключ массива default_hook. Он определяет хук, который будет использоваться для получения данных из «фичи». Я думаю ни для кого не секрет что «фича» это модуль. Мы реализуем в этом модуле хук metatag_export_default и совместим туда экспортируемые данные. Остальные хуки я вынес в отдельный файл metatag.features.inc

Еще один важный момент, это то что hook_features_api является обычным хуком и работает как ИМЯ_МОДУЛЯ_features_api. Остальные хуки о которых пойдет речь, формируются с использованием имени экспортируемого компонента вместо имени модуля как обычно. Например хук features_export_options.

В этом хуке мы возвращаем массив с пунктами, которые можно переносить через «фичу». В случае с модулем metatag это массив указателей на варианты настроек мета тегов для различных типов страниц (например global, node, taxonomy_term).

/**
 * Implements hook_features_export_options().
 */

function metatags_features_export_options() {
  $instances = metatag_config_instance_info();
  foreach ($instances as $key => $instance) {
    $options[$key] = $key;
  };
  return $options;
}

Эти пункты станут доступны в соответствующем разделе metatags при создании новой «фичи»

Следующий хук features_export_render, он формирует код для файла «фичи», в котором хранятся экспортируемые данные.

/**
 * Implements hook_features_export_render().
 */

function metatags_features_export_render($module_name, $data, $export = NULL) {
  $code = array();
  $code[] = ‘ $config = array();’;
  $code[] = »;
 
  foreach ($data as $key => $name) {
    if (is_object($name)) {
      $name = $name->instance;
    }
    if ($config = metatag_config_load($name)) {
      $export = new stdClass();
      $export->instance = $config->instance;
      $export->config = $config->config;
      $export = features_var_export($export, ‘ ‘);
      $key = features_var_export($name);
      $code[] = " // Exported metatags config instance: {$name}.";
      $code[] = $config[{$key}] = {$export};";
      $code[] = "";
    }
  }
  $code[] = ‘ return $config;’;
  $code = implode("n", $code);
  return array(‘metatag_export_default’ => $code);
}

В хук передается массив $data. Он содержит те самые пункты, которые вы выбрали при создании «фичи», на первом скриншоте. По этим пунктам формируется примерно такой код

Обратите внимание что в коде хука и на скриншоте фигурирует тот самый хук metatag_export_default, который мы определили в самом начале в features_api.

Хук features_export позволяет записать данные в массив $export, используя массив $data. Также тут можно усложнить структуру хранимых данных разделив их на категории.

/**
 * Implements hook_features_export
 */

function metatags_features_export($data, &$export, $module_name = », $type = ‘metatags’) {
 
  foreach ($data as $name) {
    $export[‘features’][$type][$name] = metatag_config_load($name);
  }
}

В массив $data передаются те пункты, которые были экспортированы через «фичу». Для этих пунктов загружается состояние которое хранится в БД.

Для того чтобы найти различия между состоянием «фичи» и состоянием в БД, используются хуки «features_export» и «metatag_export_default». Первый получает состояние из БД, второй возвращает состояние данных в «фиче». Эти состояния сравниваются и вы можете увидеть различия как на скриншоте

В случае если возникли различия между «фичей» и состоянием в базе, возможны два варианта.
Первый это обновить фичу, например с помощью команды drush fu ИМЯ_ФИЧИ. В этом случае используются хуки features_export и features_export_render. В результате код фичи будет обновлен в соответствии с состоянием в базе.

Второй вариант это revert — сбросить состояние в базе на то, что хранится в «фиче». Для того чтобы сделать revert потребуется хук features_revert.

/**
 * Implements hook_features_revert().
 */

function metatags_features_revert($module) {
  $function = "{$module}_metatag_export_default";
  $feature_conf = $function();
  if ($default_config = features_get_default(‘metatags’)) {
    foreach (array_keys($default_config) as $config) {
      if ($conf = metatag_config_load($config)) {
        db_delete(‘metatag_config’)->condition(‘instance’, $config)->execute();
      }
      unset($feature_conf[$config][‘cid’]);
      $object = new stdClass();
      $object->cid = NULL;
      $object->instance = $config;
      $object->config = $feature_conf[$config][‘config’];
      metatag_config_save($object);
    }
  }
}

В самом хуке потребуется реализовать код, который обновляет данные в базе в соответствии с кодом в «фиче».
Вот и все, надеюсь эта статья будет полезной.

Ссылка на патч для модуля metatag

ссылка на оригинал статьи http://habrahabr.ru/post/155709/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *