Informa a Drupal 8 sobre tu módulo utilizando el archivo .info.yml

Tema principal: metadatos del proyecto

El archivo .info.yml (también llamado “archivo info yaml”) es una parte fundamental de un módulo, tema o perfil de instalación en Drupal 8, ya que almacena los metadatos del proyecto.

Estos archivos .info.yml son necesarios para:

• Informar a Drupal sobre la existencia de un módulo, tema o perfil de instalación.
• Distinguir entre diferentes tipos: tema, módulo, perfil.
• Proporcionar información para las páginas de administración de la interfaz web de Drupal.
• Especificar criterios para la activación/desactivación del módulo y su compatibilidad con la versión de Drupal.
• Otros objetivos administrativos en diferentes contextos.

Para más información, consulta la última API sobre InfoParserInterface.php. (Haz clic en Ver fuente.)

Hello World

A continuación se muestra el archivo hello_world.info.yml que vamos a utilizar. Si sigues los pasos, crea un nuevo archivo hello_world.info.yml en la carpeta raíz de tu módulo y pega este código en él.

name: Hello World Module
description: Crea una página que muestra "Hello World".
package: Custom

type: module
core: 8.x

Vamos a revisar cada línea para ver su función.

Las primeras tres líneas se utilizan principalmente en la interfaz de administración, donde los usuarios pueden activar o desactivar tu módulo. Las claves name y description proporcionan el texto que aparece en la página de administración de módulos, mientras que la clave package permite agrupar módulos similares. Por ejemplo, el Core utiliza package: Core para agrupar todos los módulos que se distribuyen con Drupal 8. También puedes usar package: Custom para agrupar tus módulos personalizados y facilitar su localización y activación.

La clave type, que es nueva en Drupal 8, indica el tipo de extensión, como módulo, tema o perfil.

Para módulos alojados en drupal.org, el número de versión será completado por el empaquetador. No debes especificarlo manualmente; simplemente omite la línea de versión.

La clave core indica con qué versión del core de Drupal es compatible tu módulo.

name, type y core son claves obligatorias.

Especificar core_version_requirement
Advertencia
Actualmente, DrupalCI no soporta parches de prueba que modifiquen core_version_requirement.

¿Necesitas core_version_requirement?

Al definir restricciones para la versión del core, se sigue el siguiente orden de prioridad:

• Si el archivo composer.json especifica el requerimiento del core, este tiene máxima prioridad.
• Si composer.json no tiene el requerimiento, core_version_requirement en info.yml tiene prioridad sobre lo siguiente.
• Si core_version_requirement no está definido en info.yml, se usará cualquier versión del core indicada en la sección de dependencias del info.yml del módulo principal.

Especificar core_version_requirement cuando sea necesario

La nueva clave core_version_requirement en los archivos *.info.yml de módulos, temas y perfiles ahora soporta el control semántico de versiones implementado por Composer. Esto permite que los módulos, temas y perfiles indiquen que son compatibles con varias versiones principales de Drupal.

Por ejemplo, un módulo compatible con Drupal 8 y Drupal 9 puede tener un archivo info.yml como este:

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

Esto indica que el módulo es compatible con todas las versiones de Drupal 8 y 9. core: es obligatorio aquí porque las versiones de Drupal Core anteriores a 8.7.7 no reconocen la clave core_version_requirement:.

Sin embargo, la mayoría de los módulos tendrán que eliminar el código obsoleto para ser compatibles con Drupal 9. Por lo tanto, no podrán ser compatibles con todas las versiones de Drupal 8.

Por ejemplo, un módulo compatible con versiones de Drupal 8 posteriores a la 8.8.0, así como con Drupal 9, necesitará un archivo info.yml como este:

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

La clave core: no debe usarse aquí para asegurarse de que versiones de Drupal anteriores a la 8.7.7 no puedan instalar el módulo. Si se agregan ambas (core y core_version_requirement), salvo en el caso core_version_requirement: ^8 || ^9, se generará una excepción.

No se puede usar core_version_requirement para restringir la versión del core hasta la 8.7.7. Por ejemplo, core_version_requirement: ^8.7 || ^9 provocará una excepción durante el análisis sintáctico: esto no está permitido, porque ^8.7 incluiría versiones como 8.7.0, que no reconocen la clave core_version_requirement:.

Esto es importante: cuando se use la nueva clave core_version_requirement con cualquier valor distinto a ^8 || ^9, el módulo debe probarse en Drupal 8.7.7 o versiones más recientes.

Ejemplo completo

Además de las propiedades básicas mostradas antes, existen muchas otras propiedades adicionales. Aquí tienes un ejemplo completo.

name: Hello World Module
description: Crea una página que muestra "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

# Nota: no añadas manualmente las propiedades 'version' o 'project'.
# Estas serán añadidas automáticamente por el empaquetador de drupal.org.
# version: 1.0
# project: 'hello_world'

• dependencies: una lista de otros módulos de los que depende tu módulo. Las dependencias de módulos del core o contrib deben usar el formato de espacio de nombres {project}:{module}, donde {project} es el nombre del proyecto tal como aparece en la URL de Drupal.org (por ejemplo, drupal.org/project/views) y {module} es el nombre de la máquina del módulo. Las dependencias también pueden incluir restricciones de versión, como webform:webform (>=8.x-5.x). Si tu módulo depende de otros módulos o bibliotecas proporcionados, deben ser declarados en el archivo composer.json del módulo. Para módulos personalizados locales que dependan unos de otros, puedes usar {module}:{module} (o {module}:{submodule} para submódulos).
• test_dependencies: una lista de otros módulos (formato igual que dependencies) necesarios para ejecutar ciertos tests automáticos de tu módulo en el sistema de testing automatizado de Drupal ("DrupalCI"), pero que no son dependencias del módulo en sí (o que están en desarrollo como dependencias modulares, pero aún no están completadas). Debes confirmar los cambios en test_dependencies en tu repositorio Git antes de intentar ejecutar un test que dependa de él; no basta con incluir el cambio info.yml en el mismo parche que el nuevo test. Alternativamente, puedes usar Composer para dependencias de testing; consulta la documentación correspondiente para más información.
• configure: si tu módulo ofrece un formulario de configuración, puedes indicar aquí la ruta a dicho formulario. Así aparecerá un enlace en la página “Extensiones” (/admin/modules) cuando el usuario despliegue los detalles.
• php: 5.6: define la versión mínima de PHP necesaria para tu módulo. Los usuarios no podrán habilitar el módulo si utilizan una versión más antigua de PHP. Esto ayuda a evitar errores si tu módulo usa funciones más recientes no presentes en versiones anteriores de PHP.
• hidden: true: esto ocultará tu módulo de la lista de módulos en la página Extensiones. Puede ser útil si el módulo solo contiene tests o es un ejemplo para desarrolladores que necesiten implementar una API del módulo principal. Puedes hacer visibles estos módulos añadiendo $settings['extension_discovery_scan_tests'] = TRUE en tu archivo settings.php.
• required: true: esto indica que tu módulo debe estar habilitado y no puede ser eliminado.
• Propiedades restringidas, añadidas por el empaquetador de Drupal. No las añadas manualmente en tu info.yml: version y project

Depuración de archivos .info.yml

El módulo no aparece en la página admin/modules

• Asegúrate de que el archivo de información se llama {machine_name}.info.yml y está en la raíz del directorio del módulo.
• Verifica que el archivo esté correctamente formateado. No debe haber espacios antes, pero sí debe haber un espacio después de los dos puntos (:). El formato debe ser como el del ejemplo anterior.
• Asegúrate de que el archivo contiene la siguiente línea:

type: module

• El nombre del módulo debe empezar con una letra o guion bajo. A continuación un extracto de la documentación PHP sobre nombres válidos para funciones.

Los nombres de funciones siguen las mismas reglas que otras etiquetas en PHP. Un nombre válido debe empezar por una letra o guion bajo, seguido de cualquier número de letras, números o guiones bajos. Como expresión regular, se expresa así: [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*.

El módulo aparece en admin/modules pero su casilla está deshabilitada.

• Verifica que la compatibilidad del core esté configurada a 8.x

core: 8.x

• Asegúrate de que todas las dependencias del módulo están disponibles. Puedes expandir la información del módulo para ver qué requisitos faltan.

Ten en cuenta que algunos módulos fueron movidos fuera del core de Drupal 8, mientras que otros módulos añadidos han sido incorporados al core o reemplazados por nuevos módulos del núcleo.

La descripción del módulo está vacía

Recuerda que el valor de description se usa para la descripción.

description: Descripción del módulo de ejemplo.

Agregar el archivo composer.json

Además de declarar dependencias de otros módulos en el archivo .info.yml, si el módulo es un módulo contribuido en Drupal.org que desea probar cambios en las dependencias usando DrupalCI como parte del desarrollo, debe tener un archivo composer.json que exprese dichas dependencias (DrupalCI solo detecta cambios de dependencias en parches que afecten composer.json, no archivos .info o .info.yml).

Consulta también

• YAML
• .info a .info.yml aviso de cambios
• Documentación API para InfoParser::parse()
• Archivos .info de módulos en Drupal 7
• Archivos .info de módulos en Drupal 6
• Definir un tema usando un archivo .info.yml
• Convertir módulos de Drupal 7 a Drupal 8 Paso 1: conversión de mymodule.info a mymodule.info.yml
• Los módulos ya no pueden añadir estilos/scripts a través de la entrada de cambio del archivo .info.yml
• Añadir composer.json