Features and Overrides – Part III

 

Overview

In our first installment (A New Paradigm for Overriding Drupal Features) I presented a new sandbox module that allowed you to override Field Settings from existing Features. In the second installment (Features and Overrides – Part Deux) I presented the Features Override 2 sandbox to handle all types of Features. In this final installment I will present the new Features Override 7.x-2.0-alpha1 module release that works with the new 7.x-1.0-rc1 release of the Features module to finally solve the problem of Overrides.

The Problem (revisited)

As a quick review, the problem we are trying to solve is dealing with site-specific changes to existing Features. The Drupal Features module allows you to capture configuration data, such as entities, fields, variables, views, permissions, etc into code modules.  These code modules can then be placed into version control, enabled and disabled, or used on a separate Drupal installation to provide the same feature.

In many cases, a Feature is developed for a generic site (or Distribution, such as OpenPublish) but needs to be slightly changed for the specific site you are developing. If you change the base distribution feature, it will be hard to upgrade to a newer version of that distribution feature. What you really want to do is just capture your changes to a site-specific "Override" feature and leave the original distribution untouched.

The Final Solution

The solution was a community effort combining the original Features Override 1.x module along with my Features Override 2 sandbox along with an experimental version of my sandbox created by hefox. The result is the 2.x release of Features Override (alpha1).

Based on community feedback, Features Override still uses existing Drupal “alter hooks” whenever possible, rather than changing the rendered exportable output. Although the original sandbox showed it was possible to achieve any override by added an alter hook to the exported code, it turned out that these alter hooks mostly existed already and just needed to be handled in a more general way. The new Features Override module maintains the easy user interface from the previous sandboxes.

New Features Release

To achieve a seamless Override solution, Features itself needed several patches. These included bug fixes to current ctools-based Features and the ability for a Feature component to specify the name of a custom alter hooks. All of these needed patches have now been rolled into the new 7.x-1.0-rc1 release of Features.

In addition to bug fixes and support for Overrides, the new release of Features also adds some new functionality:

  • In the list of Features, each Feature name now links to the view of that exported feature (for admins)
  • A new drush “fc” (feature-components) command can be used to list components matching a wildcard pattern.
  • The drush “fe” (feature-export) command uses the new component wildcard patterns and also replaces the previous “feature-add” functionality.
  • Conflicts with disabled features are less emphasized in the feature listing.
  • Package name for a feature can now be changed in the UI.
  • Exportables can now define their own “alter” hook name (for Override support) as well as write different code to different files.
  • Provides a stable and supportable module for Drupal 7 (no longer Beta!)

Features Override 2.x

The alpha1 release of Features Override defines two new types of component exportables. The first allows you to export all of the changes (add/deletes/changes) to an existing component:

Override_screen1

The new “View” button will display a popup list of the changes to the specific component.

The second type is for advanced users and allows specific line-by-line control over which changes are exported to the override feature:

Override_screen2

Clicking the Refine button expands the component to show each add and delete. You simply check or uncheck the box to include the change in the override exportable.

A new “Review Overrides” screen is also provided to display all of the changes with better context information than the previous “diff” display. Rather than creating a new tab as I described in the previous blog, the existing “Review Overrides” tab is used. The previous “diff” information is still included at the bottom if you have the Diff module installed. But even without the Diff module, the Features Override module will provide a much more useful display of what has changed on your site.

Override_screen3

Notice the new upper section that displays all of the relavent changes more concisely and with the name of the view and name of view display being changed compared with the raw code “diff” shown below.

Bonus Level!

If you are still reading this, then you deserve something extra: I have attached a pdf copy of my Features & Overrides slides from DrupalCamp Maryland. Enjoy!

And thanks to everybody who attended the Features BoF at DrupalCon Denver on Tuesday. Great to see the interest in Features & Overrides and to put faces with some of the names in the issue queue.

Conclusion

The new Features Override module has been designed to be easy for site builders to use. It now works with the released version of Features. No more special patches are needed. You can start playing with Features Override on your real web site projects. It’s possible that not all feature type will work because we now rely upon existing alter hooks. However, the API exists for each feature component to define it’s own alter hook. If your favorite feature component is not supported, post to their issue queue and ask them to support Features Override — it’s very easy for them to do now. With working support for Views and CTools-based features, Features Override should finally start to get the kind of usage and support that it deserves. It’s a very important tool in the Drupal site-builders toolbox for building complex sites built upon distributions and custom features.