Обзор конфигурации (в сравнении с другими типами информации)

В Drupal 8 есть несколько типов информации:

• Content

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

• Session

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

• State

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

• Конфигурация

Информация о вашем сайте, которая не является контентом и изменяется нечасто, например, название вашего сайта, типы контента и просмотры, которые вы определили, и т. д.

• Кэш

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

• Настройки

Информация только для чтения для вашего сайта, жестко запрограммированная в файле settings.php.

Решить, как классифицировать вашу информацию

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

• Конфигурация и состояние: если ваша информация должна быть развернута с вашего сервера разработки на ваш действующий сервер, это, вероятно, информация о конфигурации, а не информация о состоянии.
• Конфигурация и контент. Подумайте, конструктор сайтов или редактор сайтов. Если роль «редактор сайта» на сайте захочет редактировать информацию, это, вероятно, контент. Если только роль «создатель сайта» хочет иметь право редактировать информацию, то это, вероятно, конфигурация. Но это не абсолютное правило.
• Конфигурация против контента: подумайте о цифрах. Если у вас огромное количество предметов, возможно, это контент. Если у вас будет только несколько, возможно, это конфигурация.
• Конфигурация против контента. Конфигурация имеет тенденцию определять «типы вещей», такие как типы контента, словари таксономии и т. д. Тогда каждая «вещь» в типе является частью контента: узел контента, термин таксономии и т. д.

Простая конфигурация против объектов конфигурации

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

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

Объекты конфигурации хранят информационные списки вещей, которые пользователи могут создавать и удалять; Ваш код будет продолжать работать нормально, будь то 0 или 100+. Пример: стили изображения, представления и т. Д. Объекты конфигурации также поставляются с полным набором хуков CRUD, которые запускаются точно так же, как и любой другой объект в Drupal, что делает их идеальным кандидатом для конфигурации, которой могут потребоваться другие модули или на которые могут реагировать другие. В качестве примера, Views использует объекты конфигурации, позволяющие создать сценарий, при котором во время выполнения запускаются перехватчики, которые позволяют любому другому модулю предоставлять конфигурацию (представления) для модуля Views. Объекты конфигурации могут иметь динамические зависимости. Как и простая конфигурация, они зависят от модуля, который их предоставляет. Например, views.view.frontpage зависит от модуля Views, но поскольку в нем перечислены узлы, он также зависит от модуля Node. Если позднее оно будет обновлено, чтобы показывать только узлы Article, оно также получит зависимость от объекта конфигурации Article (node.type.article). И так далее.