Working with features

The Features module is an outstanding solution for exporting module or site configuration that resides in the database as source code within a module. This has the following benefits:

  • Features can store menus, user permissions, site settings, views, and contexts, among many others. Each of these is a feature component
  • You can check which feature components have changed in the database by comparing them against the source code in the feature
  • Features, as modules, can be installed in other sites, which helps reusability
  • The source code of a feature can be version-controlled like any other module

Note

You should have basic skills of using the Features module, through the administration interface, in order to make the most out of the following examples. A good place to start is at the documentation home page at http://drupal.org/node/580026.

In this example, we will create a view, add it to a feature, change the view, and see how the feature reflects this change. Here are the steps:

  1. Go to Structure | Views | Add new view, create a simple view that lists nodes of type page with the title Simple Node Listing.
  2. Download and install Features and Diff modules. The latter is used to view the differences between configuration in the database and in the feature.
    $ drush pm-download features diff
Project features (7.x-1.0-beta6) downloaded to [success] /home/juampy/projects/drupal/sites/all/modules/contrib/features.
Project diff (7.x-2.0) downloaded to [success] /home/juampy/projects/drupal/sites/all/modules/contrib/diff.
$ drush pm-enable --yes features diff
The following extensions will be enabled: features, diff
Do you really want to continue? (y/n): ydiff was enabled successfully. [ok]
features was enabled successfully. [ok]

    Tip

    The prompt asking for confirmation to continue is using drush_confirm(), which receives the question to ask and returns TRUE or FALSE.

  3. Create a feature to store the view you created in code. For this, we will make use of the features-export command, which accepts a feature name and a list of components to add to it. We will first list the available feature components to find the one with the name of our view:
    $ drush features-export
...
views_view:frontpage
views_view:glossary
views_view:comments_recent
views_view:simple_node_listing
views_view:taxonomy_term
views_view:tracker
dependencies:block
...
  4. The feature component name of our view is views_view:simple_node_listing. Now, we can call the features-export command to create a feature called feature_node_listing:
    $ drush features-export feature_node_listing views_view:simple_node_listing
Created module: feature_node_listing in [ok] sites/all/modules/feature_node_listing
  5. If you open the source code of any of the files at sites/all/modules/feature_node_listing, you will see that it holds all the settings of the view Simple Node Listing. This will be used later on to track changes on its configuration.
  6. Now if we list all features with feature-list command, we will see our feature:
    $ drush features-list
Name Feature Status State
feature_node_listing feature_node_listing Disabled
Features Tests features_test Disabled

    Tip

    Keep in mind that features are modules whose code is generated automatically by Features. As such, they can be treated like any other module through the project management commands such as pm-enable, pm-list, and others.

  7. Our feature is listed, but its status is Disabled. We will enable it like we would do for a normal module so we can track its State:
    $ drush pm-enable feature_node_listing
The following extensions will be enabled: feature_node_listing
Do you really want to continue? (y/n): y
feature_node_listing was enabled successfully. [ok]
$ drush features-list
Name Feature Status State
feature_node_listing feature_node_listing Enabled
Features Tests features_test Disabled
  8. Now, let's change something at the Simple Node Listing view to see how the State changes. Go to Structure | Views | Edit Simple Node Listing view and change the page display name to Node Listing. Save your changes and then in the command line list all features again as in the following example:
    $ drush features-list
Name Feature Status State
feature_node_listing feature_node_listing Enabled Overridden
Features Tests features_test Disabled
  9. Our feature shows an Overridden state. This means that the configuration in the database does not match with the one in the feature code. As we have installed the Diff module, Features can print a list of differences with the features-diff command. the following are the current differences between the Simple Node Listing view in the database and the one in our feature:
    $ drush features-diff feature_node_listing
Legend:
Code: drush features-revert will remove the overrides.
Overrides: drush features-update will update the exported feature with the displayed overrides
Component: views_view
);
< /* Display: Page */
< $handler = $view->new_display('page', 'Page', 'page'),
---
> /* Display: Node listing */
> $handler = $view->new_display('page', 'Node listing', 'page'),
$handler->display->display_options['path'] = 'simple-node-listing';
,
)
  10. The previous output prints the differences using the syntax of the diff command from Linux. We can clearly see in the highlighted lines that, currently, the title of the page display is Node listing in the database, while in the feature module it is Page.

    Tip

    In order to format the differences with colors, Features checks if the terminal supports them by checking the value of one of Drush's environment variables through drush_get_context('DRUSH_NOCOLOR').

  11. When a feature is in an Overridden state, we can either revert it or update it. Reverting a feature means to push what is in the source code to the database (thus, setting the title back to Page), while updating a feature means pulling what is in the database into source code (hence keeping the page title to Node Listing). Both actions will set the feature back to a default state. Here is how we could update it using features-update:
    $ drush features-update --yes feature_node_listing
Module appears to already exist in sites/all/modules/feature_node_listing
Do you really want to continue? (y/n): y
Created module: feature_node_listing in [ok]
sites/all/modules/feature_node_listing
  12. Alternatively, the features-revert undoes the changes we did on the view:
    $ drush features-revert --yes feature_node_listing
Do you really want to revert views_view? (y/n): y
Reverted views_view. [ok]
  13. Reverting or updating a feature, changes its status to default. If we list features again, we will not see the Overridden status:
$ drush features-list
Name Feature Status State
feature_node_listing feature_node_listing Enabled
Features Tests features_test Disabled
  • The State column is blank now, which means that our feature is again in a default state. This means that its configuration in code matches with the one in the database.

Once a feature module has been created, we can still add more components to it. Imagine, that we want to add the permission to administer views to our existing feature. We will first list the available feature components by giving the feature name to the features-add command and then add it: 

$ drush features-add feature_node_listing
Available components
...
user_permission:change own username
user_permission:cancel account
user_permission:select account cancellation method
user_permission:administer views
user_permission:access all views
views_view:archive
views_view:backlinks
...
$ drush features-add feature_node_listing "user_permission:administer views"
Module appears to already exist in sites/all/modules/feature_node_listing
Do you really want to continue? (y/n): y
Created module: feature_node_listing in [ok]
sites/all/modules/feature_node_listing

The previous command added the permission to administer views to our feature. Note that, as the feature component name has spaces, we wrapped it with quotes so Drush will not take it as two different feature components. If you view the source code of sites/all/modules/feature_node_listing, you will see that it holds both (the view and the permission).

The Features module is normally used to propagate configuration and data to other Drupal instances and to highlight when a component has changed. Module configuration can be added to a feature by installing the Strongarm module (http://drupal.org/project/strongarm) and a fine-grain level of component picking can be achieved with the Features Plumber module (http://drupal.org/project/features_plumber). There are many other modules which support or extend Features which can be found at http://drupal.org/project/modules by searching the Features Package category.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.59.192