As a site builder I want to override the environment settings in settings.php

Here's an example how we used to set it in the settings.php with the drupal 6 module:

$conf['apachesolr_host'] = 'localhost';
$conf['apachesolr_port'] = '8983';
$conf['apachesolr_path'] = '/solr';

Just noting a use-case we'll want to make sure we handle:

Environment config can be stored in the database or in exportable data via a Feature. My opinion is that the settings.php data should override both database and feature data. @nick_vh, do you agree?

Example:

/**
 * Implements hook_apachesolr_environments().
 */
function myfeature_apachesolr_apachesolr_environments() {
  $export = array();

  $environment = new stdClass;
  $environment->api_version = 1;
  $environment->env_id = 'my_env_id';
  $environment->name = 'My Solr Environment';
  $environment->url = 'http://localhost:8093/solr/myenv';
  $environment->service_class = '';
  $environment->conf = array(
    'apachesolr_read_only' => '1',
  );
  $export['myfeature'] = $environment;

  return $export;
}

The following code in settings.php should override this feature:

$conf['apachesolr_environment']['my_env_id']['url'] = 'http://prod.solr.example.com/solr/myenv';

As a result, my customizations in settings.php could be quite small. Or, I could add entire environment definitions, should I choose to do so.

Sorry, I need to clarify that my last comment was on an instance that has the latest patch in #1357588: follow-up for import (needs to be optionally available when ctools is enabled) applied, which allows the config to be exported.

It feels gross to add a third place (settings.php) that this value can come from (after DB and features export), but I don't think there's a better option given Drupal core's (lack of) support for exported configuration at present. Hopefully D8 will make this better, but for now I cannot think of a less-bad alternative.

Here's a small patch that appears to do the job. Locally, it's working against 7.x-1.x as well as 7.x-1.x with #1357588: follow-up for import (needs to be optionally available when ctools is enabled) applied.

So... what's the use case?

Well, you could also apply a SQL scrub?

We want to feature-ize the configuration, because other features (eg Views) will depend on the machine name, but if it's featurized then we cannot override the connection string per-site. That's the problem.

You could set the global $conf to test?

Would love to see this feature added. I rebuild dev and staging machines with prod data frequently and this would save me the trouble of reconfiguring the environments.

Is Crell's use case solved? : "We want to feature-ize the configuration, because other features (eg Views) will depend on the machine name, but if it's featurized then we cannot override the connection string per-site. That's the problem."By exporting the apache_search_page and not the apachesolr_environment, I still seem to get the feature flagged as "overridden". Does anyone else have this problem?

I ended up re-doing things, and it seems to be working ok now.

Updated issue summary.

Is this supported at this moment on 7.x-1.x ? I can't seem to get it to work, and considering this issue is still open after five years I began to wonder if this actually work.

The correct way to use this is:

$conf['apachesolr_environments']['env_id']['name'] = 'Core1';
$conf['apachesolr_environments']['env_id']['url'] = 'http://localhost:8983/solr/core0';
$conf['apachesolr_environments']['env_id']['etc...'] = '...';

Note the conf variable: not apachesolr_environment but apachesolr_environments