Making your Drupal Module Features-Exportable
Ever wondered how you could make your module compatible with Features?
First things First, you would not always need to make changes to your module to allow your module configuration exportable to Features.
As long as you have all your module configuration stored in Drupal’s variable table (ie using variable_set), you can export such configuration through Features simple by enabling Strongarm module.
Once you enable Storngarm module, all your module’s (as well as other modules’) configuration (from variable table) is available for export. Here is a screengrab from the Feature Creation Page, with the strongarm module enabled. As you can see, all your variable are now available for export.
If enabling strongarm module does everything for you, then why would you need to modify your module to add Features support?
Because, as an example - you module might have configuration that is stored in custom tables. In such a case, exporting your module configuration is not so simple as in the case of variable configuration exported through strongram. That is when you would be required to make your module feature compatible! Or probably, you might want the admin of the site using your module (simple_fb_connect in this example) to have a better ‘feature-export’ experience. Say, I wish the admin of the site to be able to select the required configuration from the module rather than having to select from the machine names of variables!
ie, if you wish to add a new section like the below one to Feature Export screen.
While trying to figure this out, I stumbled upon 2 excellently presented blog posts that detailed the process in very fine detail:
Presented below is the list of steps in making the module simple_fb_connect compatible with features. The aim of this code change is to add a section to the Features Creation screen that would allow the configuration related to the module (Application ID and Secret) to be easily selected and added to a feature export without having to install strongarm or having to select the appropriate variables from the huge list giving a better “Feature-Export-Experience” to the admin.
Step 1: Implement hook_features_api in your .module file
File – This tells Features where we are going to be putting all of our Features-related code and therefore to include it at the appropriate times.
Default Hook – This is the function that will get called when a feature is enabled (we’ll get to this later)
Feature Source – This tells Features to make this component available when first creating a feature from scratch
Note the component name that we defined - simple_fb_connect_config . Most of the hooks that we are using going forward are Component Hooks - ie, they are prefixed by this component name and not the module name.
The list of Features Component Hooks we are going to use are:
To summarise what these hooks perform:
hook_features_export_options - defines the objects that are included in the exported component. In our example, we have defined one component called “Simple Facebook Connect Configuration” which comprises two objects, which are from the module’s configuration - The App ID and App Secret
hook_features_export - When we select an item(object) to export, what needs to be included? What dependencies should be included? These are all defined under this hook.
hook_features_export_render - This is the hook that Features will be using to generated the information we want it to write out to code, which will in turn be used to import the configuration or data in other places. The ultimate goal of this function is to dynamically create a snippet of php code that will be used during the install process to duplicate the configurations we’re exporting here. This code snippet will be exported to the Features include file.
If your module is storing configuration in custom tables, this is where you will write the corresponding SELECT queries to retrieve the configuration related to the objects being exported.
hook_features_revert and hook_features_rebuild - In most cases, hook_features_revert will just be a call to hook_features_rebuild again. hook_features_rebuild will define what do with the configuration values retrieved from the code when the feature is enabled. In case your module stores configuration in a custom table, the corresponding INSERT queries should go here.
That’s it. Once you put in your code under all the above hooks, your module is Features-Compatible! A couple of things to note:
All above hooks are component hooks and the “hook_” should be replaced by the Features Component name that you gave in your .module file’s hook_features_api
All these hooks’ code is placed in the file mentioned under ‘file’ for the component in your hook_features_api
Let us see the corresponding code for all the above hooks involved in making the couple of configuration objects exportable for the simple_fb_connect module.
NOTE: This module does not involve any custom tables. Hence in hook_features_export_render and hook_features_rebuild, I am using variable_get and variable_set respectively instead of any database queries.