Last updated October 29, 2015. Created on September 17, 2009.
Edited by ashish_nirmohi, nedjo, samwilson, cothrun. Log in to edit this page.

In Drupal 7, many site settings and configuration are made exportable. Features module offers a well-known method of bundling these exportables in a new downloadable feature module.

So, here's the thing: If someone asks you how to make a blog on a Drupal site, you don't tell them to activate the Blog module (which is ready for retirement). You tell them that a blog is easily made with custom content types, fields, and Views – and some settings that would cover 2–3 pages of fine print.

Features module shortcuts the work with configuring settings by providing comfortable means for bundling, exporting and importing settings for many of the most used Drupal modules. Features shifts the site development paradigm from tweak here and there into enabling features.

The main advantages

  1. Newcomers to Drupal can quickly deploy a blog, an image gallery and a bunch of other features, while still being able to peek into the fine-print settings.
  2. Developers can easily reuse settings in some of the most used modules, including Views, Panels, Context, and more.
  3. Developers can easily distribute their configurations to customers and developing sites – and update existing ones. There are interesting discussions on distributed features servers.
  4. For those of you using Drush: There are some useful Drush commands for managing Features. (Documentation section yet to be written — see project page for brief documentation.) For those of you not using Drush: Check it out!

Drush Ctools Export Bonus offers a more light-weight approach to exporting site configuration.

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


mausolos’s picture

Maybe broken down into "avoid at all costs" vs, "you probably don't want this"?
An example of a worst-case scenario (
Here's a start:
- anything indicating a timestamp (*_last_cron, for example, or *_index_last)
- anything involving cache (cache_*, *_cache), except possibly cache_lifetime
- anything involving installation-related variables, possibly? (intall_task, install_profile, etc)
- content_schema_version
- css_js_query_string
- (anything else?)


"It would be a dangerous undertaking for persons trained only to the law, to constitute themselves final judges of the worth of pictorial illustrations."
-- Justice Oliver Wendell Holmes Jr.

hgmartini’s picture

anything involving installation-related variables, possibly? (intall_task, install_profile, etc)

I agree. In particular, install_profile caused me problems.

anything indicating a timestamp (*_last_cron, for example, or *_index_last)

Other timestamps to possibly ignore: cron_last, ctools_last_cron, node_cron_last, update_last_check.

And a few more variables:

  • additional_settings__active_tab_*
  • cron_key
  • email__active_tab
  • features_codecache
  • features_semaphore
  • file_private_path
  • file_public_path
  • file_temporary_path
  • javascript_parsed
  • language_default (this one should be included but I don't think it works with Features)
  • maintenance_mode

Maybe Features or Strongarm should keep a list of known unneeded/dangerous variables and warn before inclusion?

TravisCarden’s picture

This might be of interest to some: #1999254: Add ability to ignore arbitrary components

JPH1000’s picture

That's a very enticing opening, "You tell them that a blog is easily made with CCK and Views – and some settings that would cover 2–3 pages of fine print." It would be nice to have a pointer to that 2-3 pages, and the Blog feature created from that, to look at, and try out.

goldhat’s picture

Does Features integrate with or provide API functions to use in Installation Profiles? I am exploring different ways to "bundle" a pre-built site so that it can be rapidly deployed. Features seems to offer a lot of potential, but I'm also considering development of an Installation Profile. Is there a way to use both? Can you bundle 1 or more features into an Installation Profile? It seems like Features is much easier to use (in concept) than programming Installation Profiles, so it would be nice to have simple commands inside an Installation Profile that say for instance "use feature feature_name;".

GoalGorilla’s picture

Features are modules.

So you can make dependencies on features.

wwward’s picture

I'm still trying to figure out what an "intergrate" is. It sounds like an ungrateful child... :-)

salientdigital’s picture

I'm new here, but not new to PHP. I'm reading the docs top down - having never worked with Drupal before at all. The docs here seem really good so far (way better than WordPress!), so kudos there. Anyway, I got to this page and had no clue what a CCK was. You may want to link to the CCK page from the "CCK" in the first paragraph. It's not clear even after reading that page whether I need to know about CCKs, given I'm working with Drupal 7.12. Or include a note that says something like, "if you are using Drupal 7 or greater, read about fields instead of CCKs."

Anthony Pero’s picture

Most of the core CCK package was moved into Drupal Core in D7. CCK provided a way to add fields to content types (and created new content types) through the GUI, rather than in code (the way Wordpress does). All of this core functionality is in Core now, and called FieldAPI... but everyone still refers to it as CCK.The CCK module for D7 mostly provides an upgrade path from D6. To answer your question directly, no, you won't "mess" with CCK, just be aware that many in the community will still refer to FieldAPI as CCK in spite of the change.

Anthony Pero
Project Lead
Virtuosic Media

xbrianx’s picture

I am trying to export all nodes of a content type into lets say a CSV or XML type of format that I can then edit and re-import using feeds. The Module Node Export is saying use features to export, but I cannot find an export button anywhere. I have searched quite a bit and even watched the screen cast but nothing that is helping me figure this out. I wish there was an easy way to export nodes.

EdoP’s picture

Being a Drupal noob, I overlooked the feature module at first, because the current text on the module home page is quite abstract (so I am really commenting on the module home page, not this page). IMHO, the text would be more convincing if it describes not just what features is, but what it is used for (such as moving functionality from test to production).
Correct me if this is the wrong place to post this suggestion. Me Drupal noob. ;).

donpwinston’s picture

You call this documentation. Good grief.

Simpler is always better.

ebanford’s picture

I've been using features and love it. I just did a presentation at Cornell's Drupal Camp on how to use features to design a custom content type, pull xml from the web and store it using feeds, and then display that content using views. I thought I'd share my detailed slides and final code in case they are helpful to anyone wanting to learn how to use features:

Feedback on ways to improve this are welcome.