Home » Developing for Drupal » Module developer's guide » 5.x

Writing .info files (Drupal 5.x)

Starting with Drupal 5.x, the concept of a .info file has been introduced to give 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 Drupal 5 to recognize the presence of a module.

The following is a sample .info file from the views_bonus module:

; $Id$
name = Bonus: panels, teasers, 2 col
description = "Show views as teasers in two columns."
dependencies = views panels
package = Views

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, and you must include the value in quotes if the value includes some punctuation:

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 until the end of the line. A comment may begin at any point on the line, thus it is especially important you quote any string that contains a comment. It is typical to place the CVS Id at the top of a .info file using a comment:

; $Id$

The .info file can contain the following fields:

name (Required)
The displayed name of your module. It should follow the Drupal 5 capitalization standard: only the first letter of the first word is capitalized ("Example module", not "example module" or "Example Module").

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

If your .info file's description (or other field) contains characters other than alphanumeric values then you must quote the string. If you need to use " in the string then you need to use the " value to display the " character.

For example, this will display correctly:

description = "This is my "crazy@email.com" email address"

This is wrong and cause Drupal to display an error when going to the modules menu:

description = This is my "crazy@email.com" address <- DO NOT DO THIS

dependencies (Optional)
A space separated list 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.

dependencies = taxonomy 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.

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

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.

In the past (before the CVS deploy module existed), it was recommended to use this:

version = "$Name$"

However, this led to much confusion and is no longer recommended. If you are a module developer, and you already have the above line in your .info files checked into the Drupal CVS repository, you should remove that line.

project (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 ini file formatting, see the PHP.net parse_ini_file documentation.

‹ Drupal's Form-handling System (for non-node data)upJavascript in Drupal 5.0 ›
» Login or register to post comments

Drupal 6 changes should be included

domasj - November 27, 2007 - 20:27

As written in the converting guide:

6.x:

name = Forum
description = Enables threaded discussions about general topics.
dependencies[] = taxonomy
dependencies[] = comment
...

Core compatibility now specified in .info filesthis title should be reviewed

As of version 6.x, Drupal core will refuse to enable or run modules and themes that aren't explicitly ported to the right version of core. For 5.x, this was implicitly true for modules, due to the existance of the .info files. For 6.x and beyond, the .info file must specify which Drupal core compatiblity any module or theme has been ported to. This is accomplished by means of the new core attribute in the .info files.

6.x:

core = 6.x

Please note that the drupal.org packaging script automatically sets this value based on the Drupal core compatibility setting on each release node, so people downloading packaged releases from drupal.org will always get the right thing. However, for sites that deploy Drupal directly from CVS, it helps if you commit this change to the .info files for your modules. This is also a good way to indicate to users of each module what version of core the HEAD of CVS is compatibile with at any given time.

PHP compatibility is specified in .info files as of version 6.x this title should be reviewed

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.

Login or register to post comments

Specify a different URL to check for status updates

febbraro - January 10, 2008 - 16:34

I have not verified that this works just yet, but I was surprised to not see mention of it anywhere. If you write a custom module that is not hosted at drupal.org, it seems you have the ability to specify the base URL that update_status will check to see if there are subsequent releases of your modules. In looking at the code it appears in your .info file you will add something like

project status url = http://some.host.com/drupal-module-updates

For example the default URL for drupal.org is http://updates.drupal.org/release-history

The format is then baseurl/modulename/version, so the url to check versions of the views moduel for drupal release 5.x is http://updates.drupal.org/release-history/views/5.x

Anyway, just came across this and thought it might help someone.

Login or register to post comments
 
 

Drupal is a registered trademark of Dries Buytaert.