Packaging Content Types and Feeds Importers

Trevor James

January 2013

(For more resources related to this topic, see here.)


Let's get started. First, we will look at some background information on what Features does. The code that the Features module will give us is in the form of module files sitting in a module folder that we can save to our /sites/all/modules directory, as we would do for any other contributed module. Using this method, we will have the entire configuration that we spent hours on building, saved into a module file and in code. The Features module will keep track of the tweaks we make to our content type configuration or importer for us. If we make changes to our type or importer we simply save a new version of our Features module.

The Features module configuration and the setup screen is at Structure | Features or you can go to this path: admin/structure/features. There is no generic configuration for Features that you need to worry about setting up. If you have the Feeds module installed as we do, you'll see two example features that the Feeds module provides—Feeds Import and Feeds News. You can use these provided features or create your own. We're going to create our own in the next section. You should see the following screen at this point:

Building a content type feature

We have two custom content types so far on our site, Fire Department and Organization Type. Let's package up the Fire Department content type as a feature so that the Features module can start to keep track of each content type configuration and any changes we make going forward.

Creating and enabling the feature

First click on the Create Feature tab on your Features administration screen. The screen will load a new create feature form. Now follow these steps to create your first feature. We're going to package up our Fire Department content type:

  1. Enter a name for your feature. This should be something specific such as Fire Department Content Type.

  2. Add a description for the feature. This should be something like This feature packages up our Fire Department Content type configuration.

  3. You can create a specific package for your feature. This will help to organize and group your features on the main Features admin screen. Let's call this package Content Types.

  4. Version your feature. This is very important as your feature is going to be a module. It's a good idea to version number your feature each time you make a change to it. Our first version will be 7.x-1.0.

  5. Leave the URL of update XML blank for now. By this point you should see the following:

  6. Now we're going to add our components to the feature. As this feature will be our Fire Department content type configuration, we need to choose this content type as our component. In the drop-down box select Content types: node.

  7. Now check the Fire Department checkbox. When you do this you'll see a timer icon appear for a second and then magically all of your content type fields, associated taxonomy, and dependencies will appear in the table to the right. This means that your feature is adding the entire content type configuration.

  8. Features is a smart module. It will automatically associate any fields, taxonomy or other dependencies and requirements to your specific feature configuration. As our content type has taxonomy vocabulary associated with it (in the form of the term reference fields) you'll notice that both country and fire_department_type are in the Taxonomy row of the feature table. You should now see the following:

  9. Now click on the Download feature button at the bottom of the screen to download the actual module code for our Fire Department feature module. Clicking on Download feature will download the .tar file of the module to your local computer.

  10. Find the .tar file and then extract it into your /sites/all/modules/directory. For organizational best practices, I recommend placing it into a / custom directory within your /sites/all/modules as this is really a custom module. So now you should see a folder called fire_department_content_ type in your /sites/all/modules/custom folder. This folder contains the feature module files that you just downloaded.

  11. Now if you go back to your main Features administration screen you will see a new tab titled Content Types that contains your new feature module called Fire Department Content Type. Currently this feature is disabled. You can notice the version number in the same row.

  12. Go ahead and check the checkbox next to your feature and then click on the Save settings button. What you are doing here is enabling your feature as a module on your site and now your content type's configuration will always be running from this codebase.

  13. When you click on Save settings, your feature should now be enabled and showing Default status.

When a feature is in Default state this means that your configuration (in this case the Fire Department content type) matches your feature modules codebase. This specific feature is now set up to keep track of any changes that may occur to the content type. So for example if you added a new field to your content type or tweaked any of its existing fields, display formatters or any other part of its configuration, that feature module would have a status of Overridden. We'll demonstrate this in the next section.

The custom feature module

Before we show the overridden status however, let's take a look at the actual custom feature module code that we've saved. You'll recall that we added a new folder for our Fire Department content type feature to our /sites/all/modules/custom folder. If you look inside the feature module's folder you'll see the following files that are the same as the constructs of a Drupal module:





  • fire_department_content_type.module

Anyone familiar with Drupal modules should see here that this is indeed a Drupal module with info, .module, and .inc files. If you inspect the .info file in an editor you'll see the following code (this is an excerpt):

name = Fire Department Content Type description = This feature packages up our Fire Department Content type configuration core = 7.x package = Content Types version = 7.x-1.0 project = fire_department_content_type dependencies[] = features

The brunt of our module is in the fire_department_content_type.features. file. This file contains all of our content type's fields defined as a series of the $fields array (see the following excerpt of code):

/** * @file * */ /** * Implements hook_field_default_fields(). */ function fire_department_content_type_field_default_fields() { $fields = array(); // Exported field: 'node-fire_department-body'. $fields['node-fire_department-body'] = array( 'field_config'=>array( 'active'=>'1', 'cardinality'=>'1', 'deleted'=>'0', 'entity_types'=>array( 0 =>'node', ), 'field_name'=>'body', 'foreign keys'=>array( 'format'=>array( 'columns'=>array( 'format'=>'format', ), 'table'=>'filter_format'

If you view the file you'll see two arrays that return the vocabs which we're referencing via the term references of our content type. As you can see, this module has packaged up our entire content type configuration. It's beyond the scope of this book to get into more detail about the actual module files, but you can see how powerful this can be. If you are a module developer you could actually add code to the specific feature module's files to extend and expand your content type directly from the code. This would then be synced to your feature module codebase. Generally, you do not use this method for tweaking your feature but you do have access to the code and can make tweaks to the feature code. What we'll be doing is overriding our feature from the content type configuration level.

Additionally, if you load your module's admin screen on your site and scroll down until you see the new package called Content Types, you'll see your feature module enabled here on the modules admin screen:

If you disable the Features module here, it will also disable the feature from your Features admin screen. The best practice dictates that you should first disable a Features module via the Features admin screen. This will then disable the module from the modules admin screen.

Overriding your feature

Our feature is now in Default status. This means it matches the module codebase. But what will happen if we need to add a field or tweak a field in our content type? This is the whole point of using Features. The Features module will detect this change for us and let us know that our module is overridden. Let's try it.

First let's make a change to our Fire Department content type. Load and edit your content type by going to Structure | Content Types | Fire Department. We're going to make a few changes, listed as follows:

  1. First change the Preview before Submitting setting to Disabled.

  2. Under Publishing options uncheck the Promoted to Front Page checkbox.

  3. Save your content type.

  4. Now go to Manage Fields. Add a brand new field called Fire Department Image with a field type of Image. On the image field settings leave all settings at default and save settings.

  5. Now load your Manage Display and tweak the Website field format to be URL, as a link. We're changing the display formatter for this field here.

  6. Save your content type.

  7. You have now tweaked some content type general configuration and you've added a new field to the type.

  8. Now go to your Features admin screen at Structure | Features. You should see that your feature is now showing as Overridden.

The Diff module

Before we inspect our override let's install the Diff module. The Diff module will be helpful to us as we inspect our feature override. This module will help to show the differences between our original feature codebase and the new tweaks we've made to it via our content type changes. This module is a huge helper module, especially when you have multiple developers working on a site at the same time and making configuration changes to content types and other items that are being synced with features.

To install Diff get the latest module version from

Install it as you would any contributed module. Go ahead and enable the Diff module and save your module configuration:

Reviewing the override

Now load your Features admin screen again and this time click on the Overridden link. The Fire Department feature configuration screen will load and you should see a Overridden status next to your fields. This is because we've made display formatter changes to our content type. We've also added a new field.

Now we can review our overrides with our newly installed Diff module by clicking on either the Overridden status link next to the fields, or clicking on the Review Overrides tab. Click on the Review Overrides tab.

Here you will see the two changes we made outlined in the diff. The first is the new image field and the second is the format type of link_url. If you make a content type configuration change such as promoting the content to the front page or disabling preview settings, these specific configurations will not show up in the diff. The diff will only show you changes to the fields you've added in our specific example here. The changes are in the right column and our existing code is on the left.

Now we need to recreate our feature module so we can capture these changes and get back to our Default synced status.

Recreating the feature

Now that we have reviewed our overrides we can recreate our feature, add the new field to it, and increment its version number. The format type tweak making the website link a link_url will be captured automatically when we recreate our feature. To do this, carry out the following steps:

  1. Click on the Recreate tab.

  2. Your feature module's config screen will load.

  3. It's very important to change the version number of your module here. You can always view the version of a feature module by looking at its .info file. We're going to change the version number to 7.x-1.1 here.

  4. Now in the Edit components drop-down box you need to locate the new Image field you've added. First select Fields: field as the type of component you want to search for and add it.

  5. Now scroll down in the fields list until you see all of your checked and selected fire department content type fields. Notice that the last field in the list is unchecked. This is the new image field. Check it to add it.

  6. Once you have added the field by checking its box, now you can click on the Download feature button to download your latest version of the module files.

  7. Extract the .tar file and replace all of your existing module's files with this new version.

  8. Once you replace the files reload your main Features admin page via Structure | Features. Your feature should have Default status and it should show the 7.x-1.1 version.

That is the Features process in a nutshell. Basically once you start using Features you'll be able to keep a very close eye on any content type, importer, or other site configuration change. Features will catch these changes for you and inform you that your Features module is in an overridden state. You'll then review the overrides, add them to your feature, and then recreate your feature.

Reverting features

There will be times when you get code replaced in your local version of your site by another developer's versions of the files. This can happen if you're using a repository to store code and update from. So if the other developer makes a configuration change on his/her version of the site and then commits this new feature module code, you'll then update your site's version with this new code. The process will be similar to recreating a feature.

When you get new code files with a change, your feature will show Needs Review status. You can click on the Needs Review link and review the changes. Now, your feature will have Overridden status just like it was before when you made your own local site changes.

In this case you may want to revert your code to the latest code in the codebase, as it has been updated from SVN or Git for example. This way you can update your local site with the other developer's code. So to do this, just click on the Revert button at the bottom of your Feature module's configuration screen. This will revert your code to the latest code files that you've pulled in your repository update and to your local. This can be one of the confusing parts of using the Features module as a whole. But just remember that this process will revert your local site's configuration to match the configuration defined in the new version of the Features module.

The Feed Importer feature

Now that we have created a feature for our content type and have practiced using the Features module let's go ahead and create a new Feature to package up our Feed importer configuration for our Fire Department content.

To do this follow these steps:

  1. Go to Structure | Features to load the main Features administration screen.

  2. Click on the Create Feature tab.

  3. Give your feature a name: Fire Department Importer.

  4. In the Package field give it a package name: Importers.

  5. From the Edit components select box, choose Feeds: feeds_importer:

  6. Check the checkbox next to the importer you want to package up; in this case it's fire_department_importer:

  7. Click on the Download feature button to download.

  8. Extract the feature module to your /sites/all/custom directory.

  9. Refresh your Features admin screen and you should see your new feature module in the new Importers tabbed package. Enable it and it should be set to the Default status:

Migrating your feature to another Drupal site

So far, we've shown how features can help you to manage changes and tweaks to your site's configuration. We've focused on how to do this using a content type and a feed importer. Another powerful feature of the Features module is that, as the module packages your configuration changes as code in the form of a custom module, you can easily move your module to another Drupal site that is also running the Features module. Then on this new site you can enable your module. When you enable your module, the module will create the content type and its associated components including taxonomy vocabs, associated Views and Panels, and more.

One note here—you need to make sure that the site you will be implementing the feature module on contains all the dependent modules that your feature module requires. In our case, the majority of the modules are part of Drupal core so we should be able to move our module and implement our content type without too much difficulty. This is a very easy method of migrating content types and configuration from one Drupal site to another. This is the perfect option for when you need to move your configuration from your local development site to a staging site, and then to a production site. You can develop completely locally, and rarely have to tweak any configuration on your staging or production site as you can simply enable your feature module.

To move your module simply copy the specific feature module folder and move it to the site you want to enable it on. You can do this via SFTP or via Git or SVN if you are using a repository to store your code. Deploy the module to the site you want to enable it on. Once the module is on the site you can load the Features administration screen on the site in question and enable your feature module. That's all there is to it.


In this article we successfully installed the Features module and built a custom feature that packages our entire Fire Department content type configuration. We showed how to download and extract our module code, and then enable our custom feature and place it into Default status.

We added a new field and tweaked some of our content type's existing configuration to test our new feature module and place it into an overridden state. Then we recreated our feature module with the new components and updated configuration and replaced our existing module files with the new ones.

Finally we took our feature module and deployed it to another Drupal website to show that we can easily take our content type and its configuration from our local development site to another Drupal site.

Resources for Article :

Further resources on this subject:

You've been reading an excerpt of:

Migrating to Drupal 7

Explore Title