Complete configuration in code functionality

Webchick says jump, I say "how high?". http://www.webchick.net/node/89

Theoretically, yes. Since Facet API uses CTools, it has Views-style exportables. I haven't tested it yet nor have I implemented the import form, which is why this issue is open. Would love someone to help out with this to speed up resolution.

Hi dynamicdan.

Thanks for the input, and I agree with the KISS philosophy 100%. I do want to make sure the module is feature complete or extensible enough for features to be added via contrib before this module goes RC1 as I will not be open to adding new features once we hit this RC state in the spirit of stability. I think an example of me taking this approach was my decision to remove the issue #1132744: Implement fieldset realm for Drupal 7 off of the D7 stable release blocker list, since this feature could theoretically be added in contrib.

Just a point of clarification, I don't think that this module suffers from a lack of testers due to being in beta. We have a healthy pool of committers including pwoalnin and drunken monkey who are the lead maintainers of the two major search contribs for D7, and it looks like we have eclipsed 1k users which means there is enough meaningful end user testing happening already.

In terms of the import / export functionality, if it had to be implemented from scratch I would remove it from the list as you recommended. However, this module is built on the CTools Export component, so exportables actually work right now. We are currently using this system to manage, load, and save all of Facet API's configurations, so completion of this issue is simply testing the default hooks that come OOB when you use CTools. Architecturally exportables are not as conducive to being pluggable as the other components in Facet API. You really have to make sure that the schema and API's are set to support this, which is 90% of the battle anyways.

I feel that this functionality is critical because I believe in the power of 10% and Drupal's ability to make a positive impact on transparency in business, government, and the internet in general if we can get there. Currently Drupal does very well in tech circles, but not so much outside of our industry. Being more on the sales side of things, I am seeing that distributions are the key factor in people not familiar with Drupal adopting the platform. Because Search API, Apache Solr Search Integration, and core Search (kinda sorta anyways) use this module for faceted browsing, it is critical that Facet API have exportable configurations in order to be included in distributions. D7 won't start taking off until the distros can catch up, and the distros require that modules are ready to do so not only from a functionality standpoint but from a configuration management standpoint as well.

Just as a side note I don't want people to think that this is a "sales" driven decision because I mentioned that word above. The reason I work for Acquia is because I feel it puts me in a position to further Drupal and search, and I moved from a tech position to a pre-sales position in order to be on the front lines of helping new people new to Drupal adopt the platform. Some in the community have questioned my motivations recently, and it really pisses me off. I have issues with anyone who questions my intentions giving my track record in contributing to the community, and I think it is unfortunate that some people will judge you based on your title as opposed to your merit. Sorry for the tangent, but I have felt the need to get that off my chest for some time.

Anyways, I am up for discussion as to whether or not this truly is a stable release blocker, but right now I am inclined to keep it on the list and am definitely looking for testers to give a stamp of approval and bring the issue home to completion. Maybe I should change the title to "test exportables" or something like that to be more clear on what needs to be done?

Thanks for the input, and sorry for the blog post.
Chris

Thanks for testing. I think that the issue here is defaults. If keys don't exist then defaults should be applied, but the export / import must be bypassing this logic.

Thanks for testing,
Chris

Updating component.

The attached patch adds the ability to export global configs as well as revert configurations. I tried exporting both local and global configs, and it seemed to work out pretty well. I used the two following hooks to test:

/**
 * Implements hook_ctools_plugin_api().
 */
function mymodule_ctools_plugin_api($owner, $api) {
  if ('facetapi' == $owner && 'facetapi_defaults' == $api) {
    return array('version' => 1);
  }
}

/**
 * Implements hook_facetapi_default_facet_settings().
 *
 * This hook can be placed in a MODULE.facetapi_defaults.inc file.
 */
function mymodule_facetapi_default_facet_settings() {
  $facets = array();

  ...
  ...

  return $facets;
}

Note that the changes that were implemented in this patch now allow you to implement hook_facetapi_default_facet_settings() in a MODULE.facetapi_defaults.inc file.

Marking as fixed. Committed changes at http://drupalcode.org/project/facetapi.git/commit/1eddcfd.

There is no graphical import, however the exporting configs to code is working which is by far the most important aspect. The graphical import / cloning will come after 1.0.

Thanks for posting. Let's open up a new issue so that if there is a fix in the code we can reference a thread with a single commit in the next release's changelog.

~Chris