Last updated March 20, 2013. Created on March 7, 2008.
Edited by Nikhil Mohan, Gaelan, Drave Robber, lpalgarvio. Log in to edit this page.

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)

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

Comments

3dloco’s picture

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

It would be great if more modules where categorized under groups/packages such that the admin/build/modules/list page is more user friendly and cuts down time when managing many modules.

With the guidelines quoted above a LOT of modules are just listed under "Other", which is really not very helpful because this is just not very intuitive or the most common way one would go about looking for a specific module. It is easier to look and group a module by what it does. A good example is the Development group/package which list all the modules for development.

klonos’s picture

... the 'package' field should be used even if it means to group only a few modules together and not only when it comes to multi-module packages or 4+ modules that depend on each other.

When using a fair amount of modules, if they happen to not specify a proper package category, then they ALL end up in the 'Other' package category and it gets pretty messy!

Please also see my comment here: http://drupal.org/node/879952#comment-3316164

Qandeel’s picture

I would say that we should also introduce a new field called conflict

e.g.

conflict[] = cck ; Means if CCK is enabled you cannot enable this module, to enable this module you have to disable CCK module

Note: this conflict field should work vise versa, if its in one module then other module will automatically see that there is a module in module list that has a conflict with me so check to see if that is enable then disable the check box and put a message that "conflicting module is enable"

Iam working on it and soon there will be a patch

Any thoughts are welcome

Muhammad Qandeel Aslam
http://qandeelaslam.com

Tomark’s picture

It seems a good idea.

AlexisWilke’s picture

I support this idea. It may never appear in Drupal 6.x, but hopefully in 7.x or 8.x...

Although since dependencies is plural, we may want this one field plural too.

Qandeel’s picture

Is this Idea going in.. I proposed this Idea long time ago and it has a great potential to get in 8.x

conflicts[] =

Muhammad Qandeel Aslam
http://qandeelaslam.com

Anonymous’s picture

I wrote my info file exactly as mentioned here:
; $Id$
name = New
description = A new module for testing
core = 6.x

and I still get the message that this version is not supored by Drupal 6.2, (my file is called New), I can't figure out what I am doing wrong.

thank you for your help

AlexisWilke’s picture

Trying adding the version parameter:

version = 6.x-1.0

and see if that works. While you are developing the first version, it may be required to force a version.

(Drupal 6.2? or 6.20?)

mau.ferrusca’s picture

I have followed every suggestion but I still get the red X.

:(

Can someone plase help me?

I have:

; $Id$
name = "Custom Name"
description = A bit of info about what the module does.
core = 6.x
package = MyModules

Thanx!

---

I made it work like this:

; $Id$
name = "Save & Edit"
description = Provides a "<a href="http://drupal.org/project/save_edit"> Save & Edit </a>"
button for node pages.
package = MauModules
core = 6.x

But package is ignored, module appears within "Other" package.

If I switch the order for package/core, then I get the "6.22 incompatibility" error.

AlexisWilke’s picture

The following looks strange to me. You use the same quotes around and in the a tag.

description = Provides a "<a href="http://drupal.org/project/save_edit"> Save & Edit </a>" button for node pages.

I would at least write it like this:

description = "Provides a <a href='http://drupal.org/project/save_edit'>Save & Edit</a> button for node pages."
ibnkhaldun’s picture

Hi.

I did not test your code. But It seems as 2 capitalized "M" -> MyModules may conflict with Drupal capitalization rule.

Try package = Mymodules

cya.

ibnkhaldun’s picture

Long time ago I had the same problem.
I solved It by adding a small text:

; $Id$ mymodule.info
name = "This is my module name"
description = "This is my module description"
package = MyPhpDrupalTools
core = 6.x

Note the first line: $Id$ mymodule.info
I don't know if it's a correct usage of $Id$ line... but works.

dtylerhuff’s picture

Just a word of caution, that it may be that you're saving that file as a .info file but your text editor isn't saving as such. This is tricky. You must ensure that the file is saved thus: The file must be saved as UTF-8 without a Byte Order Mark (BOM).

otherwise you may get that error as you reported.

sdowney2002’s picture

I believe that:

files[] = xxxx.module

(where xxxx is the name of the module file)

is also required in the .info file

jcfiala’s picture

files[] is not required in Drupal 6, although some other modules may look for it.

--
-john

RichardLynch’s picture

I don't know git, and I don't even understand this, really, but I know Drupal is not in CVS any longer, so it's outdated, whatever it's trying to say...

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

D34dMan’s picture

It just means that if you get the modules from CVS GIT ... you will have to add the version information manually.

___________________________
And they say my Jokes are Bad.