Last updated June 22, 2015. Created on August 28, 2007.
Edited by holingpoon, davidneedham, NonProfit, gisle. Log in to edit this page.

The .info file is a static text file for defining and configuring a theme. Each line in the .info file is a key-value pair with the key on the left and the value on the right, with an "equals sign" between them (e.g. name = my_theme). Semicolons are used to comment out a line. Some keys use a special syntax with square brackets for building a list of associated values, referred to as an "array". If you are unfamiliar with arrays, have a look at the default .info files that come with Drupal and read the explanations of the examples that follow. Even though the .info file extension is not natively opened by an Application, you can use TextEdit on a Mac or Notepad on a Windows computer in order to view, edit, and save your changes.

Note that this page describes .info files used for Drupal themes, and not modules. For information about the structure of .info files for Drupal modules, see Writing .info files in the Module developer's guide.


The following example shows the Drupal 6 .info file for the Garland theme:

name = Garland
description = Tableless, recolorable, multi-column, fluid width theme (default).
version = VERSION
core = 6.x
engine = phptemplate
stylesheets[all][] = style.css
stylesheets[print][] = print.css

Theme name requirements

The name should start with an alphabetic character, can contain numbers and underscores, but not hyphens, spaces or punctuation. The name will be used by Drupal in forming various functions in PHP and therefore it has the same limitations.

Do not choose names that are already used by installed modules, as all installed components must have unique names.

One of the best practices is to use prefixes when naming a site's custom theme, to guarantee unique names for themes. A site named might use theme names such as ex_themename.

Because the .info file is cached, you must clear the cache before any changes are displayed in your site.

The .info file can also specify which theme settings should be accessed from the Drupal administration interface, as you will soon see.


The file must be saved as UTF-8 without a Byte Order Mark (BOM).


Drupal understands the keys listed below. Drupal will use default values for the optional keys not present in the .info file. See the examples set for core themes.

name (required)

The human readable name can now be set independently from the internal "machine" readable name. This imposes fewer restrictions on the allowed characters.

name = A fantasy name
description (recommended)

A short description of the theme. This description is displayed on the theme select page at "Administer > Site building > themes".

description = Tableless multi-column theme designed for blogs.

The optional screenshot key tells Drupal where to find the theme's thumbnail image, used on the theme selection page (admin/build/themes). If this key is omitted from the .info file, Drupal uses the "screenshot.png" file in the theme's directory.

Use this key only if your thumbnail file is not called "screenshot.png" or if you want to place it in a directory outside of your theme's base directory (e.g. screenshot = images/screenshot.png).

screenshot = screenshot.png

More details on creating a screenshot for the administration page.

version (discouraged)

The version string will automatically be added by when a release is created and a tarball packaged. So you may omit this value for contributed themes. However, if your theme is not being hosted on the infrastructure, you can give your theme whatever version string makes sense.

version = 1.0
core (required)

From 6.x onward, all .info files for modules and themes must indicate what major version of Drupal core they are compatible with. The value set here is compared with the DRUPAL_CORE_COMPATIBILITY constant. If it does not match, the theme will be disabled.

core = 6.x

The packaging script automatically sets this value based on the Drupal core compatibility setting on each release node. So people downloading packaged themes from will always get the right thing. However, for sites that deploy Drupal directly from git, it helps if you commit this change to the .info file for your theme. This is also a good way to indicate to users of each theme what version of core the HEAD of git is compatible with at any given time.

engine (required in Drupal 6)

The theme engine, which is used by the theme.
Drupal 6: If none is provided, the theme is assumed to be stand alone, i.e., implemented with a ".theme" file. Most themes should use "phptemplate" as the default engine.
Drupal 7: In Drupal 7, this line is no longer necessary because PHPTemplate is assumed by default.

PHPTemplate's job is to discover theme functions and templates for the behavior of the theme. Omit this entry only if you know what you are doing.

engine = phptemplate
base theme

Sub-themes can declare a base theme. This allows for theme inheritance, meaning the resources from the "base theme" will cascade and be reused inside the sub-theme. Sub-themes can declare other sub-themes as their base, allowing multiple levels of inheritance. Use the internal "machine" readable name of the base theme. The following is used in Minnelli, the sub-theme of Garland.

base theme = garland

More details are available on the page Sub-themes, their structure and inheritance.


The block regions available to the theme are defined by specifying the key of 'regions' followed by the internal "machine" readable name in square brackets and the human readable name as the value, e.g., regions[theRegion] = The region name.

If no regions are defined, the following values are assumed.

Drupal 6 default regions:

regions[left] = Left sidebar
regions[right] = Right sidebar
regions[content] = Content
regions[header] = Header
regions[footer] = Footer

Drupal 7 default regions:

regions[header] = Header
regions[highlighted] = Highlighted
regions[help] = Help
regions[content] = Content
regions[sidebar_first] = Left sidebar
regions[sidebar_second] = Right sidebar
regions[footer] = Footer

You can override the values for your specific needs.

If you override regions in D7, you are obliged to declare the line regions[content] = Content. If you want any of the default regions in your theme, you have to declare them as well.
More details are available on the page Blocks, content and their regions.


Various page elements output by the theme can be toggled on and off on the theme's configuration page. The "features" keys control which of these check boxes display on the theme's configuration page. This is useful for suppressing check boxes for elements not defined or used by a theme. To suppress a check box, omit the entry for it. However, if none are defined, all the check boxes will display due to the assumed defaults.

The example below lists all the available elements controlled by the features key.

Drupal 6 features

By commenting out the primary_links and secondary_links elements, their check boxes are suppressed and are not seen by site administrators.

features[] = logo
features[] = name
features[] = slogan
features[] = mission
features[] = node_user_picture
features[] = comment_user_picture
features[] = search
features[] = favicon
; These last two disabled by redefining the
; above defaults with only the needed features.
; features[] = primary_links
; features[] = secondary_links

Drupal 7 features

features[] = logo
features[] = name
features[] = slogan
features[] = node_user_picture
features[] = comment_user_picture
features[] = comment_user_verification
features[] = favicon
features[] = main_menu
features[] = secondary_menu

More details are available on the page Custom theme settings.

theme settings
You can use theme settings placed in .info file, to set the features by default "checked" or "unchecked" in your theme. By placing:

settings[toggle_"feature"] = 0 to uncheck setting

Where "feature" is example logo, favicon etc. that where mentioned earlier.

Example default settings:

Drupal 7

settings[toggle_logo] = 1
settings[toggle_name] = 1
settings[toggle_slogan] = 1
settings[toggle_node_user_picture] = 1
settings[toggle_comment_user_picture] = 1
settings[toggle_comment_user_verification] = 1
settings[toggle_favicon] = 1
settings[toggle_main_menu] = 1
settings[toggle_secondary_menu] = 1

More details about Advanced theme settings.


Traditionally, themes default to using style.css automatically and could add additional stylesheets by calling drupal_add_css() in their template.php file. Starting in Drupal 6, themes can also add style sheets through their .info file.

stylesheets[all][] = theStyle.css

Starting in Drupal 7, themes no longer default to using style.css if it is not specified in the .info file.

More details are available in the style sheets section.


Traditionally, themes could add Javascripts by calling drupal_add_js() in their template.php file. Starting in 6.x, if a file named script.js exists in the theme directory then it is automatically included. However, in Drupal 7, this behavior has been changed again so that script.js is only included if it has been specified in the .info file:

scripts[] = myscript.js

More details are available in the JavaScript & jQuery section.


This defines the minimum PHP version the theme will support. The default value is derived from the DRUPAL_MINIMUM_PHP constant, which is the minimum required version for the rest of core. This can be redefined for a newer version if needed. For most themes, this should not be added.

php = 4.3.3

Example .info files from core themes

theme administration display

name = Garland
description = Tableless, recolorable, multi-column, fluid width theme (default).
version = VERSION
core = 6.x
engine = phptemplate
stylesheets[all][] = style.css
stylesheets[print][] = print.css

; Information added by packaging script on 2008-02-13
version = "6.0"
project = "drupal"
datestamp = "1202913006"

Minnelli sub-theme of Garland.:

name = Minnelli
description = Tableless, recolorable, multi-column, fixed width theme.
version = VERSION
core = 6.x
base theme = garland
stylesheets[all][] = minnelli.css

; Information added by packaging script on 2008-02-13
version = "6.0"
project = "drupal"
datestamp = "1202913006"

Note that everything from the line "; Information added by packaging script on 2008-02-13" and down is added by the packaging script. You should never manually add the project and datestamp keys. The version key added manually (in the first section) allows sites to use your theme when taken directly from git.

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


wdmartin’s picture

Naively, I assumed that I could add a link to the Google Analytics script by adding this line to my theme's .info file:

scripts[] =

Sadly, this will not work. It took me a long time to track down the problem, but it appears that when Drupal loads the .info file into a theme object during initialization, it renders the above line like this:

[""] => "themes/Nefertari/"

Note the "themes/Nefertari/" part in front of the URL. Subsequently, Drupal recognizes that the URL is malformed and drops it, so that no trace of the line from the info file winds up in the completed HTML. It took me over an hour to wade through the execution flow to find this out.

Furthermore, it appears that you can't use drupal_add_js() in your template.php file either, because it can't handle external JavaScript files in 6.x. People have been working on this issue for about 13 months now, and it looks as though they might conceivably get it fixed in Drupal 7.

In the meantime, your options for linking to external JavaScript files are limited. You can:

  1. Download a copy of the file, put it in your theme folder, and then you can use your .info file to link to it. Of course, you'll then be stuck updating the script every time the original one on the other domain changes.
  2. Hard code it into your theme.
  3. Create a custom template file for your theme and load it using a preprocess function.

I've opted for the third method. First I created a file called external-js.tpl.php in my theme directory, containing this:

Then, in my template.php file, I created a pre-process function that loads that into a variable and adds the appropriate JS function call to $footer:

function Nefertari_preprocess_page(&$vars){
    $path = drupal_get_path('theme', 'Nefertari');
    $vars['external_js'] = theme_render_template($path.'/external-js.tpl.php', $vars);
    $vars['footer'] .= '	_uacct = "UA-GOOGLE-ID"; urchinTracker(); ';

Lastly, I modified page.tpl.php to print the variable $external_js right after $script in the header. I could also have printed it right before the footer, and that might have been better for performance. There's actually a module for Google Analytics already, but it doesn't fit my needs very smoothly (it's designed for single sites, when I'm working with a multi-site install of nearly a hundred distinct Drupals).

jadakren’s picture

I needed to include the wowhead.js script in the header of my site and initally made the same mistake as 'wdmartin'.

His/her instructions are great apart from the external-js.tpl.php step.

You should omit the <?php ?> tags and just have that file contain the normal html text to include a js.

file: external-js.tpl.php

<script type="text/javascript" src=""></script>
wdmartin’s picture

I think those PHP tags may have been added by drupal -- my original external-js.tpl.php didn't have them.

alexkb’s picture

As discussed here:

In Drupal 6.x you can use drupal_set_html_head() for enabling external js files in your modules. If there is a better way than this, please reply. Thanks.

Ramsos’s picture

To include a js script in the header of the website, the best way is to add/edit the theme_preprocess_html hook in your theme template.php file in order to add a call to the drupal_add_js method.

 * Override or insert variables into the html template.
function theme_preprocess_html(&$vars) {
  //include the js file in the header
  //example :  drupal_add_js(path_to_theme().'/js/google-analytics.js');

Personnaly, I prefer to list in my file only "homemade" scripts and I include third-party scripts in the preprocess_html hook

nazarioa’s picture

I am a newb at this drupal bit. I am trying to make to add google fonts via this external-fonts.tpl.php

The part I am stuck with is the "Lastly, I modified page.tpl.php to print the variable $external_js right after $script in the header."
How do I load my variable external_fonts

XiaN Vizjereij’s picture

You should maybe mention that Drupal automatically adds the theme folder in front of the entries in scripts[]


scripts[] = /sites/all/mytheme/myscript.js

Would be interpreted as


In other words, what you type there must be relative to the theme folder.

KingOfMyCastle’s picture

Just to stop anybody else banging their head against a brick wall. If you are defining ANY regions in your Drupal 7 theme's info file you MUST include the line
regions[content] = Content

If you do not you will see the "This version is not compatible with Drupal 7.x and should be replaced" message on the Appearance page.

reinaart’s picture

I didn't find this link at first when looking around for theming.

Maybe a not to whoever wrote the code that checks for: regions[content] to add a better error description instead of the totally useless "Not drupal 7 compatible" message.

I'm guessing there is a reason regions[content] needs to exists..... Bad programming......

Sigh.. better error messages make the world keep turning, instead of grinding to a halt! And makes the bad programming less... painful..

bensoi’s picture

yeah, content region in D7 is a must! once, i logged out from the site to see the user's end page but then when i tried to login back as admin, the login form is nowhere to be found! and then i found out that it requires the content region. :)

dcrocks’s picture

'regions_hidden' is not documented here, nor in any other place than . It should be clear that the code expects a definition of the form regions_hidden[] = 'machine name' and not regions_hidden[machine name] = 'human name' . It should be doubly clear that using 'regions_hidden' without a corresponding 'regions' statement for the specified region can lead to unexpected results.

David Rocks

dcrocks’s picture

There are 2 other 'region' arrays that are loaded into the .info array for every theme:
overlay_regions[] = 'machine name'
overlay_supplemental_regions[] = 'machine name'
From the code it is clear that these region arrays were not meant to be used only by core. But there is no UI for their use and no documentation outside of code. I could see the possibility of a themer wanting to use these arrays to modify admin overlay display.

The dashboard module also adds some of its regions to the 'regions' and 'overlay_regions' arrays. It does some magic to prevent other modules seeing these regions but I have seen some bug reports of users tripping over these regions. Should these be documented?

David Rocks

anithegregorian’s picture

Seems like a stupid question but during development many absurd idea's pop out...

If a theme has a region:


It might also have a logo on the left and menu on the right, so would this work:


Then in your theme you could write something like:

print render $page['header']['logo'];
print render $page['header']['primary_menu'];

Instead of rendering the whole header region and then defining each elements of that region in code, it would rather be simple to put it this way? The only thing we missout on this is how to print the whole header region... Again its a thought haven't tried it actually on D7.

dcrocks’s picture

You can create as many regions as you want now, why do you need subgroups? You can modify .info file to look like:

regions[header] = Header
regions[banner] = Banner
regions[primary_menu] = Primary menu

and page.tpl to look like:

print render $page['banner'];
print render $page['header'];
print render $page['primary_menu'];

And then use the admin/structure/blocks menu to assign content(or not) to those regions. Certainly makes page.tpl easier to read, doesn't it?

ps. Also, doesn't this use of subgroups imply using .info file to layout structure?

David Rocks

eojthebrave’s picture

The engine line is no longer required in Drupal 7 files and defaults to phptemplate if not set.

davidneedham’s picture

It's true that engine is not officially required in Drupal 7, but several people have reported that it can occasionally cause errors in php. *shrug* Better safe than sorry, eh?

Screenack’s picture

This may be a bug I'd be happy to file, if I could figure out where to file it. To the core queue, if at all? is an issue where the packaging script that adds a line which causes issues with drush and updates. There are similar reports on other starter themes. It doesn't seem to be a needed definition, so should the packager stop adding this line, or would removing it impact somewhere else?

syntheticMedia’s picture

Basically as the title implies, I have a js file I would like to add to all pages except admin pages, Can this be specified in .info or should i use the traditional drupal_add_js() on my tpl's (D6)? thanks!

davidneedham’s picture

Nope, but a couple ways come to mind. You could use an admin theme which does not include the js for the administrative pages. Seven is a wonderful admin theme you could use. Alternatively you could add the js via template.php after checking if the current page is admin.

syntheticMedia’s picture

Thanks David, can you either tell me how to check for admin page in template.php or show me wehre I can find more info? Ideally I would like to check for admin and any node/edit pages and exclude the js. Note, I am using root candy as admin theme and a zen subtheme, any suggestions? Thanks!

davidneedham’s picture

The easiest way should be to include the js in your zen subtheme but not the root candy admin theme. Since one only shows when you're not on an admin page and the other only shows when you are on an admin page, it should only use the js during non-admin pages.

Alternatively if you wanted to check the url, you could check to see if arg(0) != admin, then insert the js.

Hope that helps. Feel free to shoot me a message through my contact form if you need additional help.

syntheticMedia’s picture

thanks David, Ill play around with this and see what i come up with

nevergone’s picture

info file: page_top and page_bottom regio in Drupal 7?

davidneedham’s picture

Officially, the documentation does indeed say that you should include them. In practice, it doesn't seem to matter one way or another. Can someone verify this?

dcrocks’s picture

The page_top and page_bottom regions are added by default if you don't specify any regions in your theme .info file.The default html.tpl.php always prints the $page_top and $page_bottom variables as 1st and last dynamic content, if they have any content. But if you specify regions in your .info file but don't add the page_top and page_bottom definitions, then that content won't have those region wrappers. There may at least be styling and/or layout consequences, and perhaps others. Or there may not. It is hard to say.
The system module always makes sure they are 'hidden' regions, so they don't show up in the admin/structure/block form, even if they weren't defined. The documentation should say that these regions are required, as is the content region. I think the drupal intent is for you to not use these regions for your own purposes, but this is one of the many foggy areas in drupal.

David Rocks

benjifisher’s picture

The Bartik theme--themes/bartik/ the keys package and settings that are not mentioned here. I think they should be added to the documentation.

digger3d’s picture

I have found that when you build a theme for D7 and you nned to include .js fule, the way is to include a line drupal_add_js('/path/to/your/js/file/myjs.js','file');
adding to - didn't help at all

Lasac’s picture

this is not correct, and that is not the way to add .js to a theme. Clear your cache or get on irc and ask how to do it, but the way you are doing it is not the right way.

wayne2011’s picture

Thanks for this, I spent a half hour looking around for something simple to solve the problem of having to install just one external script on one lonely page. Your solution worked perfectly.

jejikson’s picture

Hellow,i manage to design a custom made interface by photoshop and i've create .info successfull and temp.tpl.php but my page still dont show text and it doesn't display top side of the page (Its like the page is too long or ?),please anybody to help on this.

a.milkovsky’s picture

also we can write media queries for stylesheets[]

stylesheets[(min-width: 480px)][] = css/480.css
stylesheets[(min-width: 768px)][] = css/768.css
stylesheets[(min-width: 1024px)][] = css/1024.css
stylesheets[(min-width: 1280px)][] = css/1280.css
dcrocks’s picture

Why not a drupal 7 example under "Example .info files from core themes"?

David Rocks

coofercat’s picture

If you have a "-" in the .info filename and/or the theme directory name, Drupal will ignore your theme

If you use the same name for your theme as you do for a module, then it causes problems too.

Both have caused me some headaches - hopefully this will save a few other people the same problems.

dcrocks’s picture

An issue already exists, #371375: Never name a module and a theme the same name!, for your second comment. Maybe you check the docs to see if no hyphen in file/directory names is a drupal standard or you can create a new issue?

David Rocks

Maarten1985’s picture

I've had the same problem using a hyphen in my theme name. Drupal 6 has no problem with it, but Drupal 7 ignores the theme completely. Didn't know that it is not allowed.

momendo’s picture

Never use # for commenting in the info file. It's invalid syntax.

# My comment <-- wrong

; My comment <-- works