Overview

Drupal uses .info files (aka, "dot info files") to store metadata about themes and modules.

For modules, the .info file is used:

• for rendering information on the Drupal Web GUI administration pages;
• for providing criteria to control module activation and deactivation;
• for notifying Drupal about the existence of a module;
• for general administrative purposes in other contexts.

This file is required for the system to recognize the presence of a module.

The following is a sample .info file:

name = "Example module"
description = "Gives an example of a module."
core = 6.x
package = Views
dependencies[] = views
dependencies[] = panels

The .info file should have the same name as the .module file and reside in the same directory. For example, if your module is named example.module then your .info file should be named example.info.

This file is in standard .ini file format, which places items in key/value pairs separated by an equal sign. You may include the value in quotes. Quoted values may contain newlines.

description = "Fred's crazy, crazy module; use with care!"

.info files may contain comments. The comment character is the semi-colon and denotes a comment at the beginning of a line. CVS Ids used to be placed at the head of info files using a semicolon, but now that Drupal.org has moved to git they are no longer included.

The .info file can contain the following fields:

name (Required)

The displayed name of your module. It should follow the Drupal capitalization standard: only the first letter of the first word is capitalized ("Example module", not "example module" or "Example Module"). Spaces are allowed as the name is used mainly for the display purposes.

name = "Forum"

description (Required)

A short, preferably one line description that will tell the administrator what this module does on the module administration page. Remember, overly long descriptions can make this page difficult to work with, so please try to be concise. This field is limited to 255 characters.

description = "Enables threaded discussions about general topics."

core (Required)

The version of Drupal that your module is for. For Drupal 6 this would be 6.x, Drupal 7 would be 7.x, etc. Note that modules cannot specify the specific version of a branch of Drupal. 6.x is correct. 6.2 is not.

core = 6.x

dependencies (Optional)

An array of other modules that your module requires. If these modules are not present, your module can not be enabled. If these modules are present but not enabled, the administrator will be prompted with a list of additional modules to enable and may choose to enable the required modules as well, or cancel at that point.

The string value of each dependency must be the module filename (excluding ".module") and should be written in lowercase like the examples below. Spaces are not allowed.

dependencies[] = taxonomy
dependencies[] = comment

package (Optional)

If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here. If left blank, the module will be listed as 'Other'. In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not.


The exception to this rule is the "Development" package, which should be used for any modules which are code development tool modules (Devel, Coder, Module Builder...).

If used, the package string is used to group modules together on the module administration display; the string should therefore be the heading you would like your modules to appear under, and it needs to be consistent (in spelling and capitalization) in all .info files in which it appears. It should not use punctuation and it should follow the Drupal capitalization standard as noted above.

package = Views

Suggested examples of appropriate items for the package field:

• Access control
• Audio
• Bot
• CCK
• Chat
• E-Commerce
• Event
• Feed parser
• Organic groups
• Performance and scalability
• Station
• Video
• Views
• Voting (if it uses/requires VotingAPI)
• Location

php (Optional)

As of version 6.x, module and themes may specify a minimum PHP version that they require. They may do so by adding a line similar to the following to their .info file:

php = 5.1

That specifies that the module/theme will not work with a version of PHP earlier than 5.1. That is useful if the module makes use of features added in later versions of PHP (improved XML handling, object iterators, JSON, etc.). If no version is specified, it is assumed to be the same as the required PHP version for Drupal core. Modules should generally not specify a required version unless they specifically need a higher later version of PHP than is required by core. See the PHP Manual for further details on PHP version strings.

hidden (Optional)

As of version 6.20, modules may specify that they should not be visible on the modules page by adding hidden = TRUE. This is commonly used with testing modules used with SimpleTest where end-users should never enable the testing modules. Can also be used with feature modules, made with the module Features.

version (Discouraged)

The version string will be added by drupal.org when a release is created and a tarball packaged. However, if your module is not being hosted on the drupal.org infrastructure, you can give your module whatever version string makes sense.

Users getting their modules directly from git will not have a version string, since the .info files checked into git do not define a version. These users are encouraged to use the Git deploy module to provide accurate version strings for the admin/build/modules page for modules in directories checked out directly from git.

Because Drupal core uses a slightly different packaging process than contributed modules, the core modules have a version line predefined. This is an exception to the rule, not the model for contributed modules.

project (Discouraged, packaging use only)

Module maintainers should not use this at all. The packaging script on drupal.org will automatically place a string here to identify what project the module came from. This is primarily for the Update status module, so that Drupal installations can monitor versions of installed packages and notify administrators when new versions are available.

For more information on info file formatting, see the drupal_parse_info_file() documentation.

Troubleshooting

I added the core = 6.x line, but my module still says "This version is incompatible with the 6.x version of Drupal core" on the modules page. What gives?

Be aware that the "dependencies" format changed between Drupal 5.x and 6.x.

Wrong:

name = Example
description = Example description
; 5.x dependency format.
dependencies = foo bar
core = 6.x

Correct:

name = Example
description = Example description
; Note the [], and that each of the dependencies is on its own line.
dependencies[] = foo
dependencies[] = bar
core = 6.x

Description and Accents

If you need to use accents, use ASCII characters. It is the only way to prevent truncating this field in the database and still have accents in the description. You cannot use utf8_encode in there.

See also:

Structure of the .info file for themes

Writing module .info files (Drupal 7.x)

Writing module .info files (Drupal 7.x)