In some cases a feature may need information from other features in order to provide appropriate settings. An example is #1175878: Allow other features to designate which content types should receive service links.

Proposed implementation:

Wherever feasible - i.e., when the required configuration is relatively succinct - a Debut feature requiring configuration instructions from other features shall rely on a .info setting in the following format:

debut[feature_name][setting] = value

where feature_name is the name of the feature, minus the 'debut_' prefix, and setting is a name given to the required setting.

The feature that requires such information (the implementing feature) is responsible for interpreting and using the configuration supplied.

If the data are required at more than install and/or enable time, the implementing feature should cache the data to avoid frequent loading and parsing of .info files.

Comments

Grayside’s picture

Grayside commented

In the case of a feature configured by a series of variables, if you export the variable, the original feature can use hook_strongarm_alter() to change the value as it sees fit. Because it can do this by simply checking if the variable is exported by strongarm, it does not represent a hard dependency but "will simply work" as needed.

In the event of content type variables that are not part of an array, you programmatically export a variable for each current content type to set this baseline.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Good point, I hadn't thought of doing it that way. Using hook_strongarm_alter() rather than inventing something more complex and custom makes perfect sense.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

I tried the strongarm approach but ran into problems. Strongarm is in effect only if the variable in question is not overridden. But in some cases we want to allow manual configuration. E.g., we want to be able to designate that given content types should receive social links, but this shouldn't prevent custom content types not delivered by features from being configured to receive them as well. If the variable is overridden, new settings introduced via strongarm won't take effect. If it's not overridden, custom settings for non-features based components can't be registered.

So I ended up using the approach I'd outlined. Not perfect--could use more review and thought.