Allow Solr host settings to be overwritten in settings.php

I could also use this feature, and this makes a lot of sense.

Nice work. I am now using this in a multi-stage environment and it's functioning correctly.

One question I have was if this is reliant of the host config being in a feature? I need the same thing however right now the config is in the DB. Would setting these variables still work or will I have to export everything out into a feature first?

ramlev: The patch does not seem to include username and password for HTTP authentication. Is there a reason for this?

I applied the patch in #12 and did a test with a Solr-server that had basic auth protecting it. Works like a charm, thanks!

Hm, I think that is not a good approach, as
* this should, if it is done, be done in the search api in a generic way
* we already got a generic way by using existant hooks (see Search API Solr Overrides or a Features based approach).

#14: None of the existing hooks support configuration through settings.php out of the box. I guess this is the primary use case for the patch.

I agree that it would be nice to have this Search API in a generic way. In that regard your module Search API Override seems like an optimal solution. Why not submit it as a patch to Search API? 5-10 lines of code does not warrant a separate module.

Thanks for the idea and your patch! It looks rather good.
However, a few things need improving:
- I think you should make the config variable a single array, with the machine name and then the individual settings as nested keys. (Similar to derhasi's Override module, just without the additional options key.)
- That way you could also get rid of the form alter magic and just delete that variable once the module is uninstalled. (Also, if you still wanted to delete the individual servers' settings when they are deleted, hook_search_api_server_delete() would be a better place to do that.) (Actually, I'm not sure you even have to delete a variable you never set yourself in the module. After all, if the user manually sets the variable, you'd think he could delete it himself, too.)
- You should reflect the fixed option values also in the settings form, instead of only disabling the elements.

@ derhasi: I think it would be hard to do this in a generic way in the Search API, as you'd have a considerably harder time reflecting this in the server's config form. Also, for other backends it might not make so much sense. And lastly, this would probably introduce an API change, which I like to avoid now.

@drunken_monkey, sorry, I have to disagree. There is a very simple and very generic approach that uses existing api and does not create any new one: @see http://drupalcode.org/project/search_api_solr_overrides.git/blob/refs/he...

Overriding it for other backends will make sense, as we are dealing with search api servers, simply by definition there might be differences for different stages.

@drunken_monkey, sorry, I have to disagree. There is a very simple and very generic approach that uses existing api and does not create any new one: @see http://drupalcode.org/project/search_api_solr_overrides.git/blob/refs/he...

As said:

you'd have a considerably harder time reflecting this in the server's config form.

On the other hand, admins should generally be aware that they've overridden the settings. If you document this properly, and maybe implement hook_help() or some other means of alerting admins to the fact that changes to the server settings won't take effect – then the problem should be largely mitigated, and a custom solution really unnecessary.

Any more opinions on this?

@drunken_monkey: I'll try to work out a solution in my sandbox that will take your notes into account and the work done in search_api_solr_overrides.module. I opened an issue in the sandbox for that #1963624: Merge functionality with search_api_solr_overrides.

A similar issue for Search API was filed in #1606732: Allow override of search index (and servers) settings in settings.php and closed in order to focus on the contrib approach like #19

I finally had some time to work on the sandbox. The lates code is in 7.x-1.x-merge. Feel free to post some review in #1963624: Merge functionality with search_api_solr_overrides.

It seems to me that the underlying issue here is that when working with features the solr server configuration can not be separated from the index configuration. Were it possible to separate the two then we could put the index configuration in one feature and use it across dev/staging/production with separate per-site server configuration, either in a separate feature module (my preference) or settings.php.

Hmmm, actually it seems my info is/was out of date. The ability to split out server/index configuration within features is now available.

Beanjammin, split of server/index was never a problem, as server and index were allways only linked by the server's machine name. The problem is/was, that maintaining different features for only providing different credentials for the solr server is much overhead. So maintaining that credentials as part of the settings.php. As mentioned above, that is now generally possible for search api, by using search api override.

Any chance of getting this out of the sandbox sometime soon?

I just promoted the project to full project: https://drupal.org/project/search_api_override

Thanks derhasi!

I think this is good to go now :)

That said, maybe this project's main project page could be updated to include a note about the new module?

Great to hear, thanks again for your work!
I've added the module to the list of extension modules in the handbook and to this module's "Pecularities" handbook section. Hopefully, this will be enough for people to find it.