New Field Bases and Instances in Features

What happened to Fields?

A few weeks ago I released the new 2.0-beta2 version of Features.  The big change in this version is the splitting of Field exports into separate Field Bases and Instances (see issue: http://drupal.org/node/1064472).  A big shout-out to community members: dasjo, ezra-g, impleri, hefox, mrfelton, gilgabar, and jrbeeman for their help with developing, improving, and testing this important patch.

Why Split Fields?

In Drupal 7, Fields were internally split into two different pieces of configuration data:  the base field definition, and a specific "instance" of a field.  The base definition contains the properties that cannot be changed when a field is shared across multiple content types, such as it's basic field-type.  The instance contains the properties specific to each content type, such as the label, widget, widget settings, display mode settings, etc. In the past, Features exported both the base and instance into a single exportable. This made it very difficult to change the instance-specific configuration for shared fields used across multiple content types. If you changed the label of a field in a different content type, the feature containing the field would be marked as overridden. You could solve this to some extent using the Features Override module, but that wasn't ideal. Splitting the Features export into two different components allows you to export the base definition within the main feature you wish to "own" the field, and then export the different instances of the field into your other Features without needing to worry about complex overrides.

The "How To" guts

Splitting Fields in the new version of Features was done in a way that maintains as much backwards compatibility as possible.  In fact, I went to great lengths to maintain compatibility with previous Field exportables.  When you install the new version of Features, none of your Field exportables will be marked as overridden.  Everything will continue to work just as it has in the past.  However, when you go to the Recreate screen for the Feature, you will see that the old Field components are marked as "deprecated" and the new field_base and field_instance components will be automatically selected for export.  When you Recreate the feature (or use "drush fu featurename") your Field exports will be automatically split into the new Base and Instance parts. After exporting the new version, you will still need to manually delete the old featurename.features.field.inc file that contained the old fields.  Features doesn't like to automatically delete any of your files.  After deleting this file, clear the drupal cache (drush cc all) and your new Feature should be working just like before except with split Base and Instance components.

Using Fields in Distributions

Splitting Fields into a separate Base and Instance will be great news for Drupal Distribution maintainers.  In the past, if your Distribution profile exported a content type, if would be difficult to use any shared fields in other site-specific content types without the base profile feature being overridden. With the new version of Features, the Distribution should export the Base definition of a Field, allowing site-specific features to export their own field instances.  Each instance can have it's own properties, while still using the master field definition stored in the base profile. Both the Drupal Commons 3.0 and Open Atrium 2.0 distributions are already using this new version of Features to better handle Field exportables.  Other distribution maintainers should play with this new version of Features and update their distributions when they are able.