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:  A big shout-out to community members: dasjoezra-g, implerihefox, 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

features.fieldsSplitting 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 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.


  • DamienMcKenna

    It’s worth noting that there are problems upgrading an existing feature to 2.0-beta2, including the old file not being removed and the new structures not always being added though the old ones are removed; see the issue queue for further details.

    • Mike Potter

      Yes, I mention the old file that needs to be removed in the blog post above. Definitely will be taking care of the issues on this before the next release.

  • Juan Pablo Novillo

    Thanks. This post helped me figure out why feature modules were overridden and un-revertable.

    Would it make sense to add a warning at admin/structure/features that shows that * files need to be manually removed?

    • Richard Schulte

      This warning is displayed when you run a ‘drush features-update’, actually

  • davereid

    So in this new system, should field bases be exported as one big feature independent of content type features? It’s unclear from this post what the default exports should look like.

    • Mike Potter

      No, this doesn’t really change how you design your features. You should never have any “big features” for all of a specific component. Always group your components by functionality. So put your bases along with your content type. The only time the difference between Base and Instance will really affect you is if you are building upon a distribution where the distribution exports the Base and your export additional instances in your own site features.

      • davereid

        I’m still running into major problems with sharing field bases across several different content types in individual features. Re-exporting those features is now removing the base fields from some features, and now declaring dependencies on random other features just for the field bases. Basically whichever module gets to ‘claim’ the field base first wins, regardless of who best should have the field base. I’m worried it’s going to start running into circular dependencies quickly. :/

        • Mike Potter

          If you have multiple content types in multiple features sharing the same field, Features has no way to guess which feature should own the base. So export the base where you want it first, *then* export the features that share it and depend upon it.

          • Peter Vanhee

            I agree with davereid that we risk running into circular dependencies very quickly. An example is the body field that is shared by most content types. With the new features module, if you have multiple features using the body field, only one of these features will get to claim the body base field (the first one you export).

            This poses a big problem on features re-usability in other sites (which is still the designed use-case of feature even if features has grown into a deployment model): you can’t simply take out a feature and use it on another site, without also taking out the feature that provided the base field, since that feature has now a dependency on the feature providing the base field..

          • Mike Potter

            There were some patches made in the recent RC4 release to improve the handling of field bases and instances that should take care of the problems davereid was having. It still has a problem of the “first export wins” so just be careful to put the base field into the correct export (or export it first).

            Splitting fields into bases and instances doesn’t actually make dependencies any worse. You still need to think about your modules and their dependencies the same as before. It’s just that now you have a bit more flexibility in handling fields (and with this flexibility requires a bit more thought).

          • Rob Wohleb

            One problem I’m seeing is the features-update-all command. If a developer accidentally runs that, it will likely wipe out any carefully crafted setup that they have done to put field bases in a master feature. The developer should be using something like git so loss of feature config in code should be minimal, but it’s still a PITA. Even if they make sure that all of the features have the master feature as a dependency, it doesn’t update the master first. This seems like a flaw in the ordering logic, but maybe not. Any ideas?

          • Paul Mackay

            Mike, are you suggesting that if building a set of Features, or a new distro, that your recommended approach would be to have a “core” Feature that contains shared field bases, and then other Features using those shared fields would depend on it?

            It would be great if the Features docs could be updated with this info and recommended ways of structuring fields, etc.

          • Mike Potter

            Maybe, but not necessarily. It really depends upon the project. Recommending ways of structuring fields and features exports is like asking for recommendations on how to structure your web site or your software project. Every project is going to have different specific needs.

            For a distro, I would *not* put all of your base fields into a single Feature. You still want to group exports by functionality. For example, in Open Atrium 2, we have an oa_core that contains the base field for Section references. But it wouldn’t be appropriate to put base fields for Discussions or Events into oa_core since that would break the modularity of plugins. The base fields for those plugins go into their specific plugin modules, just like they did before base and instance were split.

          • Paul Mackay

            Thanks for replying :) The approach I’m thinking is to put some common fields that will be used across many of the other content types in a Core module, and then keep fields in features that (as you say) are specific to those features.

          • Thomas Svenson

            Late to the party here and have found this thread most enlightening. I’m working on a new site and will use Features for it and it will also contain many shared fields and many content types.

            Currently I am leaning against having one or several features containing just the shared base fields. My reasoning for this is that it will make it easier to organize and manage as I won’t have to think twice about where to put them.

            I also believe it will be easier to manage dependencies when adding or changing site features. As well as make collaboration easier as and when more people join.

            Would be great to get your experienced feedback on this think Mike.

  • emjayess

    This still trips me out. Mainly due to the unavoidable arbitrary and arcane resulting dependencies; but also of course the confusion for whom drupal feature dev is a new thing.

    In my pipe dream, content types packaged into features simply (sic) check for the presence or absence of the base field configuration each requires, and either takes action (if base config = absent) or smiles and moves along (if base config = present)… which would have happy side effects of our features remaining atomic and retaining true portability, and “just work” without being so darn meticulous.

    Also, perusing around the web (and destinations like Drupal’s stackexchange) reveals that in practice, people are indeed going with (and advising) dedicated features to house field_bases… so it seems like the fallout of this in practice is drifting from what I gathered to be the intended theory of organizing fields in features.