Let Drupal 8 know about your module with an .info.yml file

Last updated on
12 July 2017

Main topic described: project metadata

An essential part of a Drupal 8 module, theme, or install profile is the .info.yml file (aka, "info yaml file") to store metadata about the project.

These .info.yml files are required to:

  • Notify Drupal about the existence of a module, theme, or install profile.
  • Provide information for the Drupal Web UI administration pages.
  • Provide criteria to control module activation and deactivation and Drupal version compatibility.
  • General administrative purposes in other contexts.

Hello World

The following is the hello_world.info.yml file that we will be using. If you are following along, go ahead and create a new file, called hello_world.info.yml, in your module's root folder, and paste this code into it:

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

type: module
core: 8.x

Looking at the info.yml file above lets take a look at each line to see what it does.

The first three lines are primarily used in the administration UI when allowing users to enable or disable your module. The name and description keys provide the text that is shown on the module administration page and the package key allows you to group like modules together. Core, for example, uses package: Core to group all of the modules provided with Drupal 8 together, likewise you might use package: Custom to group all of your projects custom modules together making them easier to locate and enable.

The type key, which is new in Drupal 8, indicates the type of extension, e.g. module, theme or profile.

For modules hosted on drupal.org, the version number will be filled in by the packaging script, you should not specify it manually, but leave out the version line entirely.

The core key specifies the version of Drupal core that your module is compatible with.

The three keys, name, type and core are required.

Complete example

In addition to the basic properties shown in the previous example there are also a number of optional properties. Here is a complete example:

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

type: module
core: 8.x

  - datetime:datetime
  - link:link
  - drupal:views

 - drupal:image

configure: hello_world.settings

php: 5.6

hidden: true

# Note: do not add the 'version'  property yourself!
# It will be added automatically by the packager on drupal.org.
version: 1.0
  • dependencies - A list of other modules your module depends on. Dependencies should be namespaced in the format: {project}:{module} where {project} is the project name as it appears in the Drupal.org url (i.e: drupal.org/project/views) and {module} is the module's machine name. Dependencies can also include version restrictions. For example, webform:webform (>=8.x-5.x). or domain:domain_access
  • test_dependencies - A list of other modules in the process of being added as dependencies of your module. This allows testbot to correctly include new dependencies when running automated tests against patches that are submitted to the issue queue when they contain a new dependency. In general, you should add and commit new test_dependencies as soon as possible when considering a new dependency. This will allow testbot to function properly during the entire development process of whatever feature requires the new dependency. Once development of the feature requiring the new dependency is complete you should move the test dependency to the dependencies section. In the example above, testbot will include the image module during tests, but sites that install the "Hello World Module" will not be required to also install the image module. Test dependencies should be namespaced in the same manner as dependencies.
  • configure - If your module offers a configuration form, then you can specify the route to this form here. It will then show up as a link in the Extend page (/admin/modules) when the user expands the details.
  • php: 5.6  - Defines the minimal PHP version that is required for you module. Users will not be able to enable the module if they use an older PHP version. This can be used to avoid errors if your module uses newer functions that did not exists in earlier PHP versions.
  • hidden: true - This will hide your module from the module list on the Extend page (/admin/modules). You might find it useful to hide a module if it only contains tests, or is intended to serve as an example for developers who need to implement the main module's API. You can make these modules visible by adding $settings['extension_discovery_scan_tests'] = TRUE to your settings.php.

Debugging .info.yml files

Module is not listed on admin/modules

  • Ensure the info file is named {machine_name}.info.yml and is located in the root of the module directory.
  • Ensure that the file has the line:
    type: module
  • Ensure the module name starts either with a letter or an underscore. Excerpt from the PHP documentation:

    Function names follow the same rules as other labels in PHP. A valid function name starts with a letter or underscore, followed by any number of letters, numbers, or underscores. As a regular expression, it would be expressed thus: [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*.

Module is listed on admin/modules but its checkbox is disabled.

  • Make sure that the core compatibility is set to 8.x:
    core: 8.x
  • Ensure that all the module dependencies are available. You can expand the module information to see which requirements are missing:
    Note that some modules have been moved out of Drupal 8 core, whereas other contributed modules have been moved into core or replaced by new core modules.

Module description is empty

  • Remember that the value of  description is used for the description.
    description: Example Module description.

See also