Last updated January 16, 2015. Created on August 6, 2009.
Edited by batigolix, arpitr, jmcejuela, NonProfit. Log in to edit this page.

Overview

Drupal uses .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;
  • providing criteria to control module activation and deactivation;
  • notifying Drupal about the existence of a module;
  • general administrative purposes in other contexts.

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

Example

The following is a sample .info file:

name = Really Neat Widget
description = Provides a really neat widget for your site's sidebar.
core = 7.x
package = Views
dependencies[] = views
dependencies[] = panels
files[] = tests/example.test
configure = admin/config/content/example

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 defines properties in key/value pairs separated by an equals sign (key = value). You may use quotation marks to wrap the value. Quoted values may contain newlines.

.info files may contain comments. A semi-colon [;] placed at the beginning of a line makes that line a comment, and that line will not be parsed.

Note: Whenever you create or change your .info file, you will need to clear your site's cache for your changes to take effect.

Properties

The .info file can contain the following properties:

Contents

name (Required)
This displays the name of your module, which will appear on the Modules page. Since module names are proper names, it should be capitalized as a proper name (e.g., "Really Neat Widget", not "really neat widget" or "Really neat widget"), and it should be a human-readable name (not really_neat_widget). If your module name includes an acronym (CSS, WYSIWYG, UI, etc.) or a third-party trade name (jQuery, JavaScript), of course follow the standard capitalization for those.
name = Really Neat Widget
description (Recommended)
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 = Provides a really neat widget for your site's sidebar.

Descriptions can contain links to documentation and sources. The following example shows a link to the author. It could be a link to a documentation node on Drupal.org. This is useful when the online documentation is better than the readme file and when you want to read about a module before switching it on.
description = Domain manager by <a href="http://petermoulding.com">Peter Moulding .com</a>.

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 minor version of a branch of Drupal. 6.x is correct; 6.2 is not.
core = 7.x
stylesheets (Optional)
Drupal 7 allows you to add CSS files in the module's .info file if it should be added on every page, just like theme .info files do. Here is an example from the node module's .info file:
stylesheets[all][] = node.css
scripts (Optional)
You can add Javascript in the module's .info file if it should be added on every page. This allows Javascript to be aggregated in an optimal way, and is the preferred method of adding Javascript that most visitors will need on a typical site visit:
scripts[] = somescript.js

For more information see Managing JavaScript in Drupal 7.

files (Optional)
Drupal supports a dynamic-loading code registry. To support it, all modules must declare any code files containing class or interface declarations in the .info file, like so:
name = Really Neat Widget
...
files[] = tests/example.test

When a module is enabled, Drupal will rescan all declared files and index all the classes and interfaces that it finds. Classes will be loaded automatically by PHP when they are first accessed.

dependencies (Optional)
An array of other modules that your module requires. If these modules are not present, your module cannot 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

In addition, test_dependencies[] can be used to indicate dependencies which are optional but recommended. At this writing they are supported only by Drupal.org's automated testing system. They cause the testbots to check out the projects suggested. Generally any modules that you have listed in the 'dependencies' array in the getInfo() function of your module's tests should be added as test_dependencies[].

test_dependencies[] = autoload

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 = Really Neat Widget
description = An example module
dependencies[] = exampleapi (1.x)

test_dependencies[] = autoload (>7.x-1.5)
...

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[] property in the .info file can also optionally specify versions:

  • = or == equals (optional: equals is the default)
  • > greater than
  • < lesser than
  • >= greater than or equal to
  • <= lesser than or equal to
  • != not equal to
dependencies[] = exampleapi (>1.0)

The above module requires any version greater than version 1.0.

You can optionally specify the core version number as well:

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

The above module requires a 7.x version compatible version of the module and a version greater than 1.5.

Additionally, multiple version dependencies can be specified as comma-separated values within the parentheses:

dependencies[] = exampleapi (>1.0, <=3.2, !=3.0)

This facility can be used to specify a minimal core version by using system as the module name:

dependencies[] = system (>=7.53)

This makes the module require at least Drupal 7.53.

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 property should only be used by large multi-module packages, or by modules meant to extend these packages, such as Fields, Views, 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. An exception to this rule is the "Development" package, which should be used for any modules which are code development tool modules.

If present, the package string groups modules together on the module administration page (admin/modules); 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.

Capitalization is important because package string is case sensitive, and using package = fields in one module and package = Fields in another would yield two different packages on the module administration page. This can be highly confusing as Seven (the default administrative theme) capitalizes fieldset legends, making fields and Fields indistinguishable. Using package = Fields is the correct way.
package = Views

Suggested examples of appropriate items for the package field:

  • Administration
  • Commerce
  • Development
  • Fields
  • Media
  • User interface
  • Views
  • Voting (if it uses/requires VotingAPI)

The Package names for contributed modules wiki tries to track current package names; this does not mean they are recommended.

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

That specifies that the module/theme will not work with a version of PHP earlier than 5.3. 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 (eg. see Release naming conventions).

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.
configure (Optional)
As of version 7.x, the path of the module's (main) configuration page.
If a module is enabled, a "Configure" and "Permissions" link appear. This will be the path of the "Configure" link for this particular module on the modules overview page.
configure = admin/config/content/example
required (Optional)
As of version 7.x, modules and themes may specify that they are absolutely required and should never be disabled by adding required = TRUE. These modules will be enabled automatically during install. In most cases it should only be used with the Drupal core required modules (e.g. Node, User, etc.).
hidden (Optional)
As of version 7.x, modules and themes 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.
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.
project status url (Only used for custom modules not submitted to drupal.org)
Allows module maintainers to define a URL to check for updates to their module using the Update status module. No module released on drupal.org should define this parameter. URL should point to an XML feed that accepts requests in the form of http://my.domain.com/projects/{project}/{core}. In that example, project status url should be set to http://my.domain.com/projects.

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:

name = Really Neat Widget
...
dependencies = foo bar   ; 5.x dependency format.
core = 6.x

Correct:

name = Really Neat Widget
...
; Note the [], and that each of the dependencies is on its own line:
dependencies[] = foo
dependencies[] = bar
core = 7.x

Description and Non-ASCII Characters

Note that if you want to use accented characters or other non-ASCII characters in your .info file's description field, you should include the HTML escaped notation, e.g., &ouml; for the "ö" character or &copy; for the "©" character.

See also

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

wjaspers’s picture

There's a push to enforce php extension dependencies not required by core on modules that need it. This is very helpful for preventing modules from being installed that depend on an extension that isn't present or enabled.
http://drupal.org/node/1322890

jhr’s picture

Need to find a package?

cd /sites/all/modules
grep -E "^\ *package\ *=" * -roh | sort | uniq
alexarpen’s picture

When using files[] directive for your classes notice that you can't use the autoload functionality for static methods.

; modules/custom/custom.info

files[] = class.row.inc

<?php
// modules/custom/class.row.inc
class MyRow {
    public static function
getCount() {
       
// get the count of all rows...
   
}
    public function
updateRow($value) {
       
// update row with the value
   
}
}
?>

Using a static method for the first time will lead to a FATAL error because the auto-loading process is invoked just when creating an instance of a class (or of an interface):

<?php
// modules/custom/custom.module

function some_hook() {

   
MyRow::getCount();
   
// This will lead to a FATAL error
}
?>

So we should either create a fake instance of class before calling the static method, or include the file containing the class declaration manually.
I actually prefer the first method because loading the file manually involves me with the name of the file.

<?php
// modules/custom/custom.module

function some_hook() {
   
    new
MyRow;
   
// This will load MyRow class automatically.
    // another way is to use module_load_include()
   
   
MyRow::getCount();
   
// now you can use the static method
   
}
?>

However there are some disadvantages to the method of creating fake instance that you should care for your case.

biligt’s picture

I noticed that in D7.12 if the .info file have encoded in UTF-8, then Modules display page throws notices and becomes strangely displayed.

wjaspers’s picture

That problem sounds like a byte-order-mark was included in the file header. Its generally good practice to avoid using BOM's because they affect the ability to load files properly.

bwood’s picture

According to Inheriting your Drupal profile from an existing distribution there is an .info file property called "base" which allows you to inherit from a base profile

base = base-profile-name

Edit: The "base" property will not work unless you apply a patch to Drupal7 core see http://drupal.org/node/1356276#comment-6117722 and the following posts.

travis uribe’s picture

Drupal requires that the class keyword in the files added in files directives be lowercase. For example, if I added in my modules .info file,

files[] = inc/ModuleClass.inc

and the file inc/MyModule.inc contained the following class definition

<?php
Class ModuleClass {
...
}
?>

the file would not be added to Drupal's class registry. Classes must be declared with class NOT Class, as was the case with all of my files. Hope this helps someone.

myselfhimself’s picture

You should also add a version number to your module's .info file
see Release naming conventions.

Example:
version = "7.x-2.1

Alan D.’s picture

This is automatically added in the packaging scripts on DO, so skip version, project, datestamp, (?core).

However, if it is never published as a project on drupal.org, then add to make the module admin pages look nicer :)

fledev’s picture

Found it a bit misguiding within the files[] description:

Classes will be loaded automatically by PHP when they are first accessed.

The Class files are autoloaded while defining them in files[]. In my case the __construct() method wasn't called at all and had to make a new instance of class to trigger it.

fuzzy76’s picture

There's nothing misleading about that. A constructor is called when an OBJECT is instantiated. Always. It is governed by the PHP language (or rather how object-orientation works in all languages), not Drupal.

--
Håvard Pedersen
Web developer at Norwegian Centre for Integrated Care and Telemedicine, working with eLearning for the health sector.

teenage’s picture

Note that an error in variable's names won't necessary throw an immediate error or a warning : Drupal doesn't seems to check the file syntax.
It will certainly generate bad formated data later, hence throwing non related errors.

Example :
namee = "my theme name"

Will throw errors PDOException ....'title' cannot be null: INSERT INTO {menu_router} on module enable/disbale.
The theme info object will contain a namee key : $theme->info['namee']

nourheine’s picture

hi , i create my module, but when i create the two files .info and .module i create text document then i renamed them ,when i clear the chaches , i don't find my module !!! any one had an idea please help me.

Tuong’s picture

I noticed that in D7.12 if the .info file have encoded in UTF-8, then Modules display page throws notices and becomes strangely displayed.

Sent from my cách làm sữa chua using drupal community