Сообщите Drupal 8 о вашем модуле с помощью файла .info.yml

Основная тема: метаданные проекта

Файл .info.yml (он же «файл info yaml») является важной частью модуля, темы или установочного профиля Drupal 8 для хранения метаданных о проекте.

Эти файлы .info.yml необходимы для:

• Сообщите Drupal о существовании модуля, темы или профиля установки.
• Различная тема, модуль по типу.
• Предоставьте информацию для страниц администрирования Drupal Web UI.
• Укажите критерии управления активацией и деактивацией модуля и совместимостью с версией Drupal.
• Общие административные цели в других контекстах.

Для получения дополнительной информации см. Последний API о InfoParserInterface.php. (Нажмите на Просмотр источника.)

Hello World

Ниже приведен файл hello_world.info.yml, который мы будем использовать. Если вы следуете дальше, создайте новый файл hello_world.info.yml в корневой папке вашего модуля и вставьте в него этот код.

name: Hello World Module
description: Creates a page showing "Hello World".
package: Custom

type: module
core: 8.x

Давайте посмотрим на каждую строку, чтобы увидеть, что она делает.

Первые три строки в основном используются в пользовательском интерфейсе администратора, когда пользователи могут включать или отключать ваш модуль. Ключи name и description предоставляют текст, который отображается на странице администрирования модуля, а ключ package позволяет группировать подобные модули вместе. Например, Core использует package: Core для группировки всех модулей, поставляемых с Drupal 8, также вы можете использовать пакет: Custom, чтобы сгруппировать все ваши собственные модули проектов, упрощая их поиск и включение.

Ключ type, который является новым в Drupal 8, указывает тип расширения, например, модуль, тема или профиль.

Для модулей, размещенных на drupal.org, номер версии будет заполнен сценарием упаковки. Вы не должны указывать это вручную, но полностью исключите строку версии.

Ключ core указывает, с какой версией ядра Drupal ваш модуль совместим.

name, type< и core являются обязательными ключами.

Указание core_version_requirement
Предупреждение
В настоящее время DrupalCI не поддерживает тестовые патчи, которые изменяют core_version_requirement.

Вам нужен core_version_requirement?

При определении ограничений основной версии используется следующий порядок приоритета.

• Если в composer.json указано основное требование, оно получает максимальный приоритет.
• Если в composer.json нет требования к ядру, core_version_requirement в info.yml будет иметь приоритет перед следующим.
• Если core_version_requirement не установлен в info.yml, то будет использоваться любая версия, указанная в основном модуле в разделе зависимостей info.yml.

Указание core_version_requirement при необходимости

Новый ключ core_version_requirement в файлах * .info.yml для модулей, тем и профилей теперь поддерживает семантическое управление версиями, реализованное в проекте Composer. Это позволяет модулям, темам и профилям также указывать, что они совместимы с несколькими основными версиями ядра Drupal.

Например, модуль, совместимый с Drupal 8 и Drupal 9, может иметь файл info.yml, подобный этому

name: My Module
type: module
core: 8.x
core_version_requirement: ^8 || ^9

Это указывает, что модуль совместим со всеми версиями Drupal 8 и 9. Core: требуется здесь, потому что версии Drupal Core до 8.7.7 не распознают ключ core_version_requirement:.

Однако большинству модулей придется удалить устаревший код, чтобы быть совместимым с Drupal 9. Поэтому они не смогут быть совместимыми со всеми версиями Drupal 8.

Например, модуль, совместимый с версиями Drupal 8 после Drupal 8.8.0, а также Drupal 9, будет нуждаться в файле info.yml, например:

name: My Module
type: module
core_version_requirement: ^8.8 || ^9

Core: ключ не должен использоваться здесь, чтобы убедиться, что версии Drupal до 8.7.7 не будут устанавливать модуль. Добавление как core, так и core_version_requirement с чем-либо кроме core_version_requirement: ^ 8 || ^ 9 приведет к исключению.

Core_version_requirement нельзя использовать для ограничения версии ядра до 8.7.7. Например, core_version_requirement: ^ 8.7 || ^ 9 вызовет исключение при синтаксическом анализе: это недопустимо, потому что ^ 8.7 будет включать версии, подобные 8.7.0, которые не распознают ключ core_version_requirement: key.

Это важно при использовании нового ключа core_version_requirement с чем-либо, кроме core_version_requirement: ^ 8 || ^ 9 этот модуль должен быть протестирован на Drupal 8.7.7 или новее.

Полный пример

В дополнение к основным свойствам, показанным в предыдущем примере, есть также ряд дополнительных свойств. Это полный пример.

name: Hello World Module
description: Creates a page showing "Hello World".
package: Custom

type: module
core: 8.x

dependencies:
  - drupal:link
  - drupal:views
  - paragraphs:paragraphs
  - webform:webform (>=8.x-5.x)

test_dependencies:
 - drupal:image

configure: hello_world.settings

php: 5.6

hidden: true
required: true

# Note: do not add the 'version' or 'project' properties yourself.
# They will be added automatically by the packager on drupal.org.
# version: 1.0
# project: 'hello_world'

• dependencies: список других модулей, от которых зависит ваш модуль. Зависимости от ядра Drupal или модулей contrib должны находиться в пространстве имен в формате {project}:{module}, где {project} - это имя проекта в том виде, в каком оно отображается в URL-адресе Drupal.org (например, drupal.org/project/views) и {module} - это имя компьютера модуля. Зависимости также могут включать ограничения версии, например, webform:webform (> = 8.x-5.x). Обратите внимание, что если ваш модуль имеет зависимости от других предоставленных модулей или библиотек, они должны быть объявлены в файле composer.json модуля. Если у вас есть локальные пользовательские модули, которые зависят друг от друга, вы можете использовать {module}: {module} (или {module}:{submodule} для подмодулей)
• test_dependencies: список других модулей (в том же формате, что и зависимости), которые необходимы для запуска определенных автоматических тестов для вашего модуля на автоматизированном тестере Drupal ("DrupalCI"), но не нужны как зависимости модуля в целом (или которые находятся в развитие как модульные зависимости, но еще не завершено). Обратите внимание, что вам нужно зафиксировать изменение test_dependencies в вашем репозитории Git, прежде чем пытаться запустить тест, который зависит от него - вы не можете просто поместить изменение info.yml в тот же патч, что и новый тест. В качестве альтернативы вы также можете использовать Composer для тестирования зависимостей - см. Соответствующую документацию для получения дополнительной информации.
• configure: если ваш модуль предлагает форму конфигурации, вы можете указать маршрут к этой форме здесь. Затем он отобразится в виде ссылки на странице «Расширения» (URL-адрес /admin/modules), когда пользователь развернет детали.
• php: 5.6: определяет минимальную версию PHP, которая требуется для вашего модуля. Пользователи не смогут включить модуль, если они используют более старую версию PHP. Это можно использовать, чтобы избежать ошибок, если ваш модуль использует более новые функции, которых не было в более ранних версиях PHP.
• hidden: true: это скроет ваш модуль из списка модулей на странице Расширения. Может оказаться полезным скрыть модуль, если он содержит только тесты или предназначен для использования в качестве примера для разработчиков, которым необходимо реализовать API основного модуля. Вы можете сделать эти модули видимыми, добавив $ settings ['extension_discovery_scan_tests'] = TRUE в ваш файл settings.php.
• required: true: это означает, что ваш модуль должен быть включен и не может быть удален.
• Ограниченные свойства, добавленные системой упаковки Drupal. Не добавляйте их вручную в info.yml в вашем хранилище: version и project

Отладка .info.yml файлов

Модуль не указан на странице admin/modules

• Убедитесь, что информационный файл имеет имя {machine_name}.info.yml и находится в корне каталога модуля.
• Убедитесь, что файл отформатирован правильно. Например, не должно быть пробелов до, но должен быть пробел после знака двоеточия (:). Форматирование должно выглядеть так, как показано в следующем примере.
• Убедитесь, что файл имеет следующую строку:

type: module

• Убедитесь, что имя модуля начинается с буквы или подчеркивания. Ниже приводится выдержка из документации PHP о допустимых именах функций.

Имена функций следуют тем же правилам, что и другие метки в PHP. Допустимое имя функции начинается с буквы или подчеркивания, за которым следует любое количество букв, цифр или подчеркивания. Как регулярное выражение, оно будет выражаться так: [a-zA-Z_ \ x7f- \ xff] [a-zA-Z0-9_ \ x7f- \ xff] *.

Модуль указан в admin/modules, но его флажок отключен.

• Убедитесь, что совместимость ядра установлена на 8.x

core: 8.x

• Убедитесь, что все зависимости модуля доступны. Вы можете расширить информацию модуля, чтобы увидеть, какие требования отсутствуют.

Обратите внимание, что некоторые модули были перемещены из ядра Drupal 8, тогда как другие добавленные модули были перемещены в ядро или заменены новыми модулями ядра.

Описание модуля пустое

Помните, что значение description используется для описания.

description: Example Module description.

Добавление файла composer.json

В дополнение к объявлению зависимостей от других модулей в файле .info.yml, если модуль является добавленным модулем на Drupal.org, желающем протестировать изменения зависимостей модулей, используя DrupalCI как часть разработки, у них должен быть composer.json, который выражает эти зависимости модуля Drupal (DrupalCI может обнаруживать изменения зависимостей только в патчах внутри composer.json, но не в файлах .info или .info.yml.)

Смотрите также

• YAML
• . info to. info. yml уведомление об изменениях
• Документация API для InfoParser::parse()
• Drupal 7 modules. info файлы
• Drupal 6 modules. info файлы
• Определение темы с помощью файла. info. yml
• Преобразование модулей Drupal 7 в Drupal 8 Шаг 1: преобразование mymodule.info для mymodule. info. yml
• Модули больше не могут добавлять таблицы стилей / скрипты через свою запись изменения файла. info. yml
• Добавьте composer.json