Writing .info files (Drupal 7.x)

As Drupal 7.x is still in development, the information here is currently a placeholder.

The .info file gives Drupal a little more information about your module. This file is used primarily by the modules administration system for display purposes as well as providing criteria to control activation and deactivation. This file is required for the system to recognize the presence of a module.

The following is a sample .info file:

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.

.info files may contain comments. The comment character is the semi-colon and denotes a comment at the beginning of a line. It is typical to place the CVS Id at the top of a .info file using a comment:

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 7 this 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 = 7.x

files (Required)

Module .info files must now specify all loadable code files explicitly. Drupal now supports a dynamic-loading code registry. To support it, all modules must now declare their code files in the .info file like so:

name = Example module
description = "Gives an example of a module."
...
files[] = example.module
files[] = example_types.inc
files[] = example.admin.inc
files[] = example.pages.inc
files[] = example.install

When a module is enabled, Drupal will rescan all declared files and index all functions and classes it finds. That means any class or function that is to be called indirectly (such as a hook) can live outside the .module file, and it will be included on-demand. Classes will be loaded automatically by PHP when they are first accessed. For functions, replace all calls to function_exists() with drupal_function_exists(), which will load the necessary file and return TRUE or FALSE depending on whether the function now exists. In the case of hooks or any code called via module_invoke*(), node_invoke(), etc. that will be done automatically.

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

If you need to specify that a certain module's version number is required Drupal 7 provides a way for this in the dependencies[] field. Version numbers are optional and only necessary if the module absolutely requires another module's specific version or branch.

The syntax for the dependencies[] field(s) is:

dependencies[] = modulename (major.minor)

Where major is the numeric major version number and minor is the numeric or alphanumeric minor version number. x can be used to denote any minor version. Some examples follow.

name = Example
description = An example module
version = 1.0
dependencies[] = exampleapi (1.x)
...

In the above .info code, the "Example" module requires an "Example API" module with the major version of 1 and any minor version.

dependencies[] = exampleapi (1.0)

This means that the module requires the 1.0 (and only the 1.0) version of the Example API module.

dependencies[] = exampleapi (1.x)

The above module requires any minor version of the module in the 1.x branch (1.0, 1.1, 1.2-beta4, etc.)

The dependencies[] field in the .info can also optionally specify operators:

• = or == equals (optional: equals is the default)
• > greater than
• < lesser than
• >= greater than or equal to
• <= lesser than or equal to

dependencies[] = exampleapi (>1.0)

The above module requires any version greater than version 1.0 is required.

You can optionally specify the core version number as well:

dependencies[] = exampleapi (>7.x-1.5)

The above module requires any minor version of Drupal 7 and any version of the module greater than 1.5.

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.

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:

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

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...).

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.

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 CVS will not have a version string, since the .info files checked into CVS do not define a version. These users are encouraged to use the CVS deploy module to provide accurate version strings for the admin/build/modules page for modules in directories checked out directly from CVS.

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 = 7.x line, but my module still says "This version is incompatible with the 7.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:

Correct:

Description and Accents

A note to all non-English speaking developers: if you need to use accents, go the ASCII way. 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 obviously.