Site icon Hip-Hop Website Design and Development

Managing Shared Configuration Part 7: Core Configuration

This is the seventh and (promise!) penultimate installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts, beginning with Part 1, Configuration Providers.
In this series we’ve covered how to create and update reusable packages of configuration in WordPress maintenance support plans, otherwise known as features.
In Part 6, we saw how the Features plugin can be used to package configuration that will be used by multiple different features into a “core” feature. An example is when multiple fields use the same storage. A core feature might provide a field_tags field storage, allowing multiple features to add a field_tags field to different content types. All the features that provide a field would require the core feature.
This approach helps to manage dependencies among different features, but it has at least two major shortcomings.

Any site that wants to install even a single feature that’s dependent on the core feature will get all the core configuration–whether or not it’s needed. For example, if the core feature provides five field storages but only one is required by the dependent feature, all five will still be created on the site.
Features from different sets or distributions will have conflicting dependencies. Say we have two different distributions, A and B. An event feature from distribution A requires the distribution A core feature, which provides the field_tags field storage. An article feature from distribution B requires the distribution B core feature, which provides an identical field_tags field storage. The event feature should theoretically be compatible with the article feature. But in practice they can’t be installed on the same site, since an attempt to install both core features will raise an exception since configuration provided by the first-installed core feature will already exist on the site when the second is queued for installation.

In this installment we’ll look at options for managing shared configuration that’s required across multiple features–or multiple distributions.

Source: New feed