Add Features support

Tested this patch. Highly useful for Features export.

The patch already seems to be applied in 7.x-1.x VCS branch since May 5th, 2015.

Importing the search index didn't work properly for me with the patch (or the latest VCS version). The default callback name in the above patch is probably wrong, but that didn't seem to fix it for me in the end either. Attached is a patch proposal for the change anyway.

I'll probably try to dig in to the problem later. I wonder if the Features support still needs to add the field type also; sarnia_entity_type_save() adds it but when I added the entity type straight to database it was missing.

The description of the patch states that server and index definitions export is handled by Search API, not this module.

I did find another issue with this patch, in that when multiple Sarnia Entity types are attempted to be exported, only one of the entities is written to the feature. This patch provides the rudimentary Features export support (hence why it was committed), but is the reasoning behind why this issue was left at Needs Work.

I have tested with both attached patches and the latest 7.x-1.1-beta5 version of this module and have been unable to successfully deploy a sarnia index using features.

In my feature I included the sarnia server, sarnia index, sarnia entity type & the solr_document field base and instance. On enabling or reverting the feature via drush I get several instances of the following error.

SearchApiException: Unknown or invalid item type sarnia_sarnia. in search_api_get_datasource_controller() (line 1904 of /Users/stephenn/Documents/workspace/yiddishbookcenter.org/docroot/sites/all/modules/contrib/search_api/search_api.module)

On closer inspection the sarnia_entity_type table exists but is empty. An attempted workaround of adding a .install file to the feature that pre-populated the sarnia_entity_type table did not remove the errors, or lead to a working index.

Current manual workaround is as follows: Remove the index and entity type from the feature. Run a deployment enabling the feature. Log in and manually set the entity type on the sarnia tab of the server admin page. Revert the feature. This only needs to be done when first creating the index, after that features will function as normal.

In the end I got Sarnia enabled in a feature by doing this:

/**
 * Enable Sarnia and it's feature
 */
function xxx_search_feature_update_1005(&$sandbox) {
  module_enable(array('sarnia'));
  module_enable(array('xxx_search_sarnia_feature'));
  // Then revert Sarnia to find the index. Doing separately to ensure correct order.
  features_revert(array('xxx_search_sarnia_feature' => array('search_api_server')));

  module_load_include('inc', 'sarnia', 'sarnia.entities');

  $sarnia_type = array(
    'machine_name' => 'sarnia_sarnia_search',
    'label' => 'Sarnia search (Sarnia index)',
    'search_api_server' => 'sarnia_search',
    'search_api_index' => 'sarnia_sarnia_search',
    'id_field' => 'id',
  );
  sarnia_entity_type_save($sarnia_type);
}

The Sarnia feature contains the views, Search API server and index related to Sarnia. This worked for us, although I think it required also a specific order for updb & fra -y.

It'd be nice if exporting Sarnia configuration to a feature would be a ”bit” easier... :)

The issue I am seeing is that the dependent generated Sarnia entity is not being selected correctly when a Sarnia index was selected. Nor was the reverse case happening correctly (the generated Sarnia index selected along with the created Sarnia entity). The original submitted patch from krlucas claimed to accomplish this but was not working for me. Attached here is a fix for his patch that did work for me.

I was able to verify from the generated feature code that the entity and the index exports were in the resulting feature.

Here's a simplified version of the patch in #8...

Small addendum to the patch in #11, to remove a maddening little typo in the comments :)