Interoperability features

Last updated on

19 December 2016

The default settings of Features should facilitate creating and maintaining configuration modules and distributions that integrate well with each other--that are interoperable.

About interoperability in Drupal features

Can you mix and match features from one feature set or distribution with those of another? For example, can you take an event feature produced for one distribution and use it on a site that was built using a different distribution?

Up to now, the answer typically has been "no". Features from different distributions or sets of features usually are incompatible due to differences in how they are architected.

Features for Drupal 8 includes plugins that are configured by default to provide best practices for features building that will, at least, open new possibilities for interoperability.

Specific ways that interoperability is supported

The following table lists specific ways that Features addresses interoperability. Many of the specifics are adapted and updated from the (dated, but still somewhat relevant) Kit feature specification.

Interoperability principle	Implementation
Namespaces
Code namespace: The code namespace includes a prefix to all PHP functions, the directory name of the feature, and the names of files used by that feature.	Generated code uses a namespace that combines the feature set (or profile) namespace and the short form namespace of a given feature. For example, if the profile's machine name is 'example' and a feature's short machine name is 'article', the feature's code namespace will be 'example_article'.
Project namespace: The project namespace is the key used for retrieving a project's update XML feed. Where possible, a feature's project namespace should match its code namespace.	The generated features may be committed to separate repositories, each with its own project namespace matching the code namespace. Alternately, they may be left as part of an install profile.
Machine name: The machine name is the machine-readable name that best describes the use case captured by a feature. A feature's machine name need not be unique. Example: 'blog', 'gallery', 'timetracker'.	Features have a short machine name, e.g., article. This is used as the namespace to match configuration items. For example, using the default Features settings, a vocabulary named 'event_type' will be added to a package 'event' that contains an 'event' content type based on the 'event' package namespace.
Configuration item namespace: The Configuration item namespace is the naming convention used for any configuration items (views, content types, etc.) included in a feature. A feature's item namespace need not be unique. Each item name should be prepended by the module machine name whenever possible. Example: 'blog_listing', not 'recent_blog_posts'.	As noted above, components named with the feature prefix will be added to the feature. More specific namespaces will be matched before general ones. For example, if the features 'event' and 'event_registration' existed, a view called 'event_registration_listing' would be assigned to the more specific 'event_registration' package.
Restrictions
Excluded configuration: Certain configuration items and types are considered restricted from use by a feature. These are items that are often more general than the use cases commonly targeted by individual packages.	The Exclude package assignment plugin includes a curated list of configuration that is excluded from packaging.