Labs
How to customise exported Drupal Features for a particular site
When a site developer exports configuration to code, all the values stored against that configurable container on the site they export from are saved into code. This container can then be taken to another site and imported exactly as it was exported. It may sometimes be desirable to customise some of the variables within the container for a particular environment later.
We all are awaiting, with eager anticipation, the results of the CMI initiative in Drupal 8, but for now the current best way of exporting site configurable into code is with the Features module. Features exports the configurable either with its own methods or by providing a neat interface for the ctools export mechanisms and it does both things very well.
An example of such a situation occurred recently for us when we wanted to export Apache Solr module search page configurations. When these are exported to code, one of the parameters is the solr environment ID which in our setup was different for each server the code was to be deployed onto. We therefore wanted to change the environment id of the search pages when they were imported.
Fortunately, the Apache Solr Drupal module uses ctools to export its configurables to code. When these are imported, a standard Drupal alter hook is called on the imported data before it is saved, the name of this hook differs depending on the type of data being exported and imported and follows the pattern hook_[default hook]_alter(&$defaults).
The example code hook for our scenario is below. We set the default Apache Solr environment id in a variable in that sites settings.php file.
/** * Implements hook_apachesolr_search_default_searches_alter(). * When loading the default search pages from the features * export, modify the default env_id of the core_search * page to be the current default for this environment * and not what is in the actual export. */ function mymodule_apachesolr_search_default_searchers_alter(&$default_search_pages) { if (!empty($default_search_pages['core_search'])) { $default_search_pages['core_search']->env_id = variable_get('apachesolr_default_environment', 'solr'); } }
Comments
You might want to take a look at the Features Override module (http://drupal.org/project/features_override). Just as Features itself creates the necessary "hooks" for putting the Apache Solr configuration into code, the Features Override module creates the necessary "alter hooks" needed to override the configuration.
First, enable your normal base Apache Solr config feature. Then make the changes the Solr environment. This will cause your Feature to be marked as Overridden. Next, wIth Features Override (the newer 2.x Beta release) installed, create a New Feature and select the Feature Override component. It will show you all of the components that are currently overridden. Select the Apache Solr config and add this override to your new feature and then export it.
Once the new override feature is installed and enabled, you should see your Apache Solr config feature no longer marked as overridden (might need to do a revert for ctools if it still says overridden).
In your original post, you are probably correct in just creating the alter hook to dynamically set the environment and override the feature. Otherwise each server would need it's own Override Feature. But just wanted to make people aware of the new Feature Override module in case they didn't know about it.
Hi mpotter, thanks for your post! features_override is certainly worth a look when you are working with features.
Add new comment