follow-up for import (needs to be optionally available when ctools is enabled)

The export function comes from ctools and the export array in hook_schema(). So you can export your configuration. But there is no way to (re-)import this configuration.

Possible solution: Do you know this issue? http://drupal.org/node/624018#comment-5278644

Basically it is one file (wysiwyg.features.inc) with some implemented features hooks. Especially the two functions wysiwyg_features_revert($module) and wysiwyg_features_rebuild($module) do the work of importing the wysiwyg configuration via a simple db_merge() and cache clear.

What do you think?

Possible steps:
- Get all defaults: features_get_default('apachesolr_search_page', $module).
- Write/merge array to database: apachesolr_search_page_save($search_page).
- Menu rebuild needed to pick up search path: menu_rebuild().

I would like to help you and write a patch for this.

Another good starting point could be this post: http://stellapower.net/content/using-chaos-tools-module-create-exportables

What do you think?

First try. I created a ctools based load and save logic for apachesolr_environments. Do the same for apachesolr_search_page will be the next step.

Subscribing, linking from #1386750: Exportables not picked up

I'll come up with another patch which adds the ctools dependency and uses ctools' export ui.

Swentel, that's great. We should join forces.

I've also been thinking about it. I think we should discuss it. On the one hand, you'll get an administration interface for free. And it'll work and look like many other modules (eg context). That's cool.

On the other hand, there will be a strong dependency between the two modules. It isn't really necessary for the core functionality of the solr module.

It will be a while before I come up with one - I need to fix other things first in january, so if you want to go further with this patch, feel free to ahead!

I think that Apache Solr environment "variables" ($environment->conf) need to be exported along with the environment, rather than as separate exportables. Additionally, it makes sense to use the Apache Solr module's own CRUD functions rather than relying on CTools exportables CRUD, because it means that environments are always updated the same way, environment variables are maintained, and caches are properly cleared afterwards.

Here's a patch that updates environment exportables to include the variables, and implements importing. I've tested this with Features, and the patch doesn't provide a UI for exporting environments other than Features. Also, I suspect that this does not work with previously exported environments/environment variables--which really shouldn't be a big deal, because exports that come from the current implementation can't be diffed or imported.

This patch can be tested by using Features to export an Apache Solr environment. There are three things to test:

• the freshly installed feature should be reported by Features as being in the "default" state
• editing the environment through the Apache Solr configuration page should cause Features to report the feature as "overridden"
• reverting the "overridden" feature should restore the default (exported) settings

These should be tested when the feature is installed on the site it was created on, AND when the feature is installed on a site where Apache Solr has not been previously configured.

I'm not sure how to automate this sort of testing in a simpletest--maybe a test module that implements hook_default_apachesolr_environments(), and checks whether the default environments are present when apachesolr_load_all_environments() is called? (CTools would be required for this test).

Unfortunately, in my testing the feature is immediately reported as "overridden" when it is installed on a fresh site, even though Apache Solr picks up the settings correctly. I'm working on a fix right now.

It looks like the CTools API "default hook" should match the API name. I made this change, but I also reduced the length of the API name--default_apachesolr_environments is fairly long, and Features uses this in a filename.

I've reviewed this patch in a couple of different contexts and it appears to work as expected. I generated Features using local Solr configs and verified that these configurations were usable once enabled. I'm receiving a couple of SimpleTest failures, however, so I'm going to queue the latest patch for a re-test.

#14: 1357588-14-apachesolr-ctools_exportables.patch queued for re-testing.

There seems to be some reset cruft in apachesolr_load_all_environments()

Using the ctools bulk exporter I get:

Notice: Undefined property: stdClass::$conf in apachesolr_ctools_environment_export() (line 2464 of modules/apachesolr/apachesolr.module).

committed to 7.x

Awesome, thanks!

Please let me know if you see any problems, or if you can explain the failure of the built-in cools exporter. I took a look at the ctools code, but didn't have enough patience to debug.

Please let me know if you see any problems, or if you can explain the failure of the built-in cools exporter.

I think that the problem with the built-in ctools exporter was that apachesolr itself only loaded environments from the database, and never from the ctools hooks, and that (before this patch) there were two separate types of exportables for environments and environment variables, instead of exporting all of the relevant configuration in one object. Technically data from two tables can be exported as one object with ctools by adding 'join' information to the hook_schema() 'export' configuration, but IMO it makes more sense to use a consistent load path.

So what I did falls into the "more sense" option?

Yeah, exactly.