Вы здесь

Удобная работа с views при деплое

Решил что неплохо бы некоторые моменты работы с dru.io освещать в публикациях.

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

Делаем свой модуль, например exported_views, в exported_views.module пишем:

/*
 * Implementation of hook_views_api()
 */
function views_exported_views_api() {
  return array('api' => 3.0);
}

/**
 * Implements hook_views_default_views().
 **/
function views_exported_views_default_views() {
  //Finds all files that match a given mask in a given directory
  //In our case, looks for any files named *.view in the /views directory
  $files = file_scan_directory(drupal_get_path('module', 'views_exported'). '/views', '/.view/');
  foreach ($files as $filepath => $file) {
    require $filepath;
    if (isset($view)) {
      $views[$view->name] = $view;
    }
  }
  //Check that there are views in the directory
  //This keeps the site from throwing errors if there are no views to return
  if ($views) {
    return $views;
  }
}

Внутри модуля делаем папку views, куда пишем свои файлы с расширением .views, например
views_exported_profile.view, где внутри будет: <?php + то что нам выдал views export в админке, получится что-то типа:

<?php

$view = new view();
$view->name = 'user_materials';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'Материалы пользователя';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['use_ajax'] = TRUE;
$handler->display->display_options['use_more_always'] = FALSE;


... обрезано, полный код на https://github.com/Niklan/Dru.io/blob/master/sites/all/modules/custom/views_exported/views/views_exported_profile.view ...

Итого:
1. мы получаем код вьюсов, разделенный по файлам где мы можем их удобно именовать, что очень прозрачно выглядит в ревизиях и не требует огромного кол-ва features модулей в проекте.
2. Все программные вьюсы могут быть в рамках 1 модуля.
3. Мы можем легко делать revert вьюсам, если кто-то что-то не то сделал через админку, возвращая их к значению в коде.

p.s. также вы можете присоединяться к разработке на https://github.com/Niklan/Dru.io )

6
13
01.07.2015 - 12:44

Комментарии

Аватар пользователя xandeadx
xandeadx – 01.07.2015 - 15:17

инклудам принято давать расширение .inc

Аватар пользователя adubovskoy
adubovskoy – 01.07.2015 - 15:27

это не единственное отступление от code style там. На орге где-то по такой стилистике был уже холивар на тему. У кого какие мнения, отпишитесь кто как думает это видеть - поправлю на inc.

Аватар пользователя adubovskoy
adubovskoy – 02.07.2015 - 10:02

Да, т.к. у них идея 1 фича = 1 модуль. Но тут фичи как-то не прижились (мероприятия были залиты фичей, остальным с ней работать не очень удобно). В деплое фичами нужно слишком много договоренностей соблюдать.

Аватар пользователя Sora
Sora – 02.07.2015 - 20:25

Супер, спасибо за статью, больше надо! :)

Аватар пользователя orb
orb – 05.07.2015 - 08:48

В деплое фичами нужно слишком много договоренностей соблюдать.

Можно подробнее. Фичи отлично деплоятся уже много лет.

Аватар пользователя adubovskoy
adubovskoy – 05.07.2015 - 11:23

это их скорее притянули за уши для решения задачи деплоя, изначально ведь идея у них другая - reusable code for many sites, не пакетный деплой одного большого сайта с последующей доработкой. Ставить отдельно Features Tools, дабы отключать раздражающее поведение при feature disable... Ну не знаю... Может нам никто не показал как их правильно готовить - тут всегда welcome, запилите ктонть на гитхабе большой поддерживаемый версионно кусок функционала на фичах, посмотрим. Сейчас Никита смотрит на раздел "мероприятия" на фичах и плюется, неудобно.

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

Аватар пользователя Chi
Chi – 05.07.2015 - 14:49

Ставить отдельно Features Tools, дабы отключать раздражающее поведение при feature disable.

А зачем disable? Фича должна быть включена всегда. Иначе не получится отслеживать статус конфигурации (default/overridden).

Аватар пользователя orb
orb – 05.07.2015 - 22:00

Ставить отдельно Features Tools, дабы отключать раздражающее поведение при feature disable.

Зачем и что это дает?
Фичи всегда остаются включены и легко отслеживаются админом, если кто-то из девелоперов пошел вручную править продакшен - сразу будет показана какие фичи изменены и что именно изменено, а дальше бить по рукам! + Удобно сделать реверт из админки.

Версионность отлично у фич реализованна, хотя есть некоторые ньюансы - как то не всегда последовательность одинаковая.

Аватар пользователя adubovskoy
adubovskoy – 06.07.2015 - 10:57

Версионность отлично у фич реализованна, хотя есть некоторые ньюансы - как то не всегда последовательность одинаковая.

в общем, можно тестнуть. Тут фичи есть, давай посмотрим как пойдет)

Аватар пользователя Niklan
Niklan – 12.07.2015 - 14:51

Раздел мероприятий как полигон для фич юзать :)

Аватар пользователя Alan Bondarchuk
Alan Bondarchuk – 22.07.2015 - 11:05

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

Аватар пользователя SAM
SAM – 23.10.2015 - 02:23

Можно дать названия: [NAME_OF_VIEW].view.inc
Все понятно и по стандарту.