Добро пожаловать в страну Features Cконфигурации Mуправления, он же FCM! Речь идет не только о функциях, и не о Управление Конфигурацией ( как представлено в Drupal версии 8). Вместо этого, это особый случай Sпрограммного обеспечения Cконфигурации Mуправления, он же SCM. В основном потому, что Функции можно рассматривать как генератор кода, в то время как сгенерированный код нуждается для переноса через несколько сред. Читайте дальше для получения более подробной информации.

1 - Плюсы и минусы использования функций

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

• Автоматизируйте развертывание изменений, внесенных на сайт разработки Drupal, на одном или нескольких целевых (предварительных) производственных сайтах Drupal (вместо развертывания вручную).
• Облегчает обмен (доставку) текущей разработкой Drupal между разработчиками/создателями сайтов Drupal (например, для создания некоторых представлений, созданных представлениями эксперт, доступный для Тематика Drupal, работающего на другом сайте разработки, для обсуждения этого представления).
• Отличная интеграция как с GIT, так и с Drush для отправки копии кода, сгенерированного функциями (на сайте разработки), на выбранные целевые (предварительные) производственные площадки.

Недостатки использования функций

• Избежать конфликтов функций и/или управлять зависимостями функций может быть непросто!
• Начать использовать его непросто Функции на существующем (производственном) сайте.
• Установить/включить модуль Функций легко (просто модуль), но научиться правильно использовать функции является серьезной проблемой.

2 - Методы упаковки функций

Использование функций то, как упаковать (составить) содержимое функции, зависит от вашего собственного воображения. Вот некоторые методы, которые можно для этого использовать.

Одна супер-функция

Это это довольно простая техника упаковки: все упаковано вместе в одну функцию (некоторые называют ее функцией "Бог"...). Кажется простым, довольно перспективным и т. Д. Но этот метод также приводит к "конфликтам" (как объяснено ниже) более или менее сразу...

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

На основе функциональности веб-сайта

Этот метод упаковки создает отдельную функцию для каждой функциональности веб-сайта, такую как:

• Функция A= реализовать "*Галерея".
• Функция B=реализация "*Блог".
• Функция C=реализовать "*Событие Календарь".

На основе разделов администратора Drupal

Этот метод упаковки создает отдельные функции для каждого (основного) административного раздела веб-сайта Drupal, который используется для создания сайта, например:

• Все необходимые модули содержатся в функции A,
• Все определения базовых полей содержатся в функции B,
• Все типы контента содержатся в функции C,
• Все разрешения содержатся в функции D,
• Все роли содержатся в функции E,
• Все переменные содержатся в функции F,
• Все (пользовательские) Представления содержатся в функции G,
• Все (пользовательские) Правила содержатся в функции H,
• И т.д.

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

IMO это также наиболее рекомендуемый подход к упаковке особенности.

3 - Снижение вероятности конфликтов в функциях и/или GIT

Не используйте повторно поля

Довольно много конфликтов, по-видимому, вызвано повторным использованием полей между несколькими типами контента. Например, в типе контента A у вас есть поле с именем машины field_somefield, которое также используется в качестве поля в типе контента B с тем же именем машины field_somefield, но которое является другим типом поля и/или некоторыми другими настройками полей, которые отличаются.

Не используя повторно поля среди типы контента, вы избегаете запуска в этой проблеме. Взгляните на интересное соглашение об именовании для имени машины ваших типов контента и полей, как показано в таблице Информационной архитектуры и документации , которая является частью статей о " Модели относительности для Drupal". Для получения более подробной информации об этом обратитесь к моему ответу на " Как мне моделировать контент (типы) с точки зрения базы данных?".

Разделение функций в зависимости от того, кто работает над тем, что

Если на одном сайте работает несколько человек, количество конфликтов можно уменьшить, организовав (= создав отдельные) функции в зависимости от того, кто над чем работает. Иллюстрацией этого может быть, как в этом примере:

• Просмотры входит в функцию A,
• Правила входят в функцию B,
• Диаграммы входят в функцию C,
• Все, что касается тематизации, входит в функцию D,

4 - Рекомендуемые среды Drupal

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

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

В идеальном мире эти логически связанные веб-сайты Drupal должны быть настроены и использоваться следующим образом:

1. Личный сайт разработчика - у каждого разработчика веб-сайта есть отдельный сайт разработчика. Когда какая-то часть разработки готова для совместного использования с кем-то другим, создается соответствующая функция, которая отправляется в промежуточную среду.
2. Сайт песочницы - это среда Drupal, которая только содержит ядро Drupal, используемое для модульного тестирования полноты одной функции. Если функция случайно имеет какие-то неожиданные зависимости (например, какой-то модуль, от которого зависит функция, который не включен в изолированной среде), то именно здесь эта зависимость станет ясной.
3. Промежуточный сайт - сюда доставляются одна или несколько функций (созданных на сайте разработчика). Это может быть просто какое-то исправление для какой-то производственной проблемы, или это может быть место, где вся разработка для нового выпуск веб-сайта является консолидированным. Если какие-либо конфликты между несколькими функциями действительно существуют, то это среда, в которой они появятся в первую очередь... и должны быть как-то решены.
4. Сайт контроля качества - после того, как промежуточная среда будет признана стабильной, пришло время перейти к соответствующим функциям и сделать их доступными также на более высоком уровне, где они могут быть использованы для тестирования качества, приемочного тестирования, объемного тестирования и т.д. На этом уровне вам следует быть предельно осторожным в разрешении любых дополнительных изменений (если таковые имеются). Потому что любое такое изменение может свести на нет все предыдущие усилия по тестированию, уже выполненные в этой среде.
5. Теневой производственный сайт - Чтобы подготовить активацию в реальном производстве, вы можете сначала дополнительно продвинуть соответствующие функции в среду, которая считается копией (тенью) вашей реальной производственной среды. Если на этом этапе в процессе миграции что-то все еще ломается, то это красный флаг для возврата некоторые из ваших предыдущих шагов. Исправьте это и повторите попытку, пока все вовлеченные стороны не одобрят изменения.
6. Производственные площадки - Если вы выполнили все предыдущие шаги, то этот шаг должен быть самоописывающимся и довольно простым. В зависимости от ваших потребностей, это может быть один сайт или что-то эквивалентное нескольким сайтам Drupal, в то время как на всех задействованных сайтах работают одни и те же версии всех функций.
7. Базовый сайт - По моему опыту, нет многие (если вообще есть) реализации Drupal, в которых используется этот тип сайта (также). Это просто копия производственного сайта(-ов), Но доступная разработчикам Drupal, тестировщикам и т. Д., Которую можно использовать для проверки того, как выглядят производственные сайты, или для обучения пользователей и т. Д. И каждый раз, когда запускается новый цикл разработки, компоненты сайта, которые будут затронуты (должны быть изменены), должны быть "каким-то образом скопированы", используя этот базовый сайт в качестве входных данных, с целью Личного Сайт для Разработки.

Очевидно, что приведенный выше перечень типов сайтов Drupal похож на идеальный мир. В зависимости от размера вашей команды разработчиков и/или доступных бюджетов для их создания и обслуживания, не все из них могут быть использованы (или доступны по цене). Этот перечень составлен по образцу лучших практик в области SCM, используемых в основном во всех крупных/глобальных корпорациях (банках, авиакомпаниях и т.д.).

5 связанных модулей

Сильная рука

В Модуль Strongarm позволяет экспортировать переменные (модулей, которые хранят свои настройки в переменных) с помощью модуля функций.

Экспорт узлов

Модуль Экспорт узлов позволяет пользователям экспортировать узлы, а затем импортировать их в другую установку Drupal.

Экспорт ролей

Модуль экспорта ролей позволяет ролям иметь имена машин и генерирует уникальный идентификатор роли (rid) на основе имени машины. Роли могут быть экспортированы с помощью Функции и получите точно такой же rid при импорте на другие сайты.

Особенности изгнания

Модуль Изгнание функций позволяет полностью исключить отдельные компоненты функций из пользовательского интерфейса функций и экспорта функций. Вот цитата об этом со страницы проекта:

Этот модуль полезен, когда есть компоненты функций, которые вы хотите убедиться, что они НИКОГДА не будут экспортированы. Если вы используете функции для создания или развертывания сайта тогда вы, вероятно, столкнулись с проблемой, когда кто-то случайно экспортировал переменные метки времени, такие как cron_last или update_last_check. Вы также можете запретить разрешения для модулей разработчика, чтобы они не увязывались с остальными разрешениями сайта, которые вы хотите экспортировать. Удаленные элементы не будут отображаться в вашем функциональном модуле ИЛИ ЛЮБОМ ДРУГОМ ФУНКЦИОНАЛЬНОМ МОДУЛЕ, поэтому используйте их с осторожностью. Для получения основного списка функций, которые никогда не следует экспортировать, см. https://www.drupal.org/node/2400531

БОБОВЫЕ

Модуль Bean делает ваши блоки экспортируемыми. Вот цитата об этом со страницы проекта:

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

Этот модуль также отлично работает в сочетании с модулями UUID и Интеграции функций UUID. Этот модуль запущен только с D7, но он уже включен в ядро Drupal 8. Видеоурок Учебник по модулю Drupal Bean - использование пользовательского интерфейса администратора Bean предоставляет отличное введение, чтобы действительно понять возможности этого модуля и то, что вы можете с ним делать (используя только методы создания сайтов, без пользовательского кодирования вовлеченный).

Среда обитания

Модуль Среда обитания имеет наибольший смысл в рабочем процессе на основе функций. Вот цитата об этом со страницы проекта:

В настройке нескольких сред (например, prod, test, dev, local) есть некоторые модули, которые вы хотели бы всегда включать или отключать в определенных средах. Каждый раз, когда вы синхронизируете базу данных, вам приходится повторно включать/отключать одни и те же модули. Хуже того, вы становитесь ленивым и продолжаете развиваться модули включены в производство.

Среда обитания предоставляет настройки для включения или отключения определенных модулей в каждой среде (среде обитания). Просто установите переменную, например, $conf['среда обитания'] = 'локальная'; в вашем settings.php файл (фактическая переменная для использования там настраивается для вашего текущего рабочего процесса). Отключение/включение модулей выполняется на hook_init.

6 - Рекомендуемые ресурсы:

• Документация сообщества о функциях.
• Часть этот ответ основан на (удивительном, я думаю) Обсуждении особенностей.
• Видеоуроки:
  • Создание объекта.
  • Возвращающиеся функции.
  • Обновление функций.
  • Создание функций правильным способом.
  • Ограничения функций.

7 - Возможные альтернативы использованию функций

Если вы не можете или не хотите (пока) использовать Функции, затем вы можете проверить, в какой степени приведенные ниже подходы/модули могут предоставить некоторую альтернативу.

Ручной экспорт/импорт

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

Копия пакета

Некоторые люди рассматривают модуль Bundle copy в качестве возможной альтернативы. Оно имеет поддержку экспорта/импорта для:

• Типы узлов.
• Таксономия.
• Пользователь.
• Поля API полей.
• Группы полей.