pattern for providing a default search API backend for finders

[joachim-n]

@ekes and I discussed how to handle search API backends in finders, with the requirements that:

• there's nice UX when you're setting things up and you get a default backend provided for you with minimum friction
• if you want different backends for different indexes you can do that too

The Directories module handles this by saving a search index with a NULL value for its backend (which is technically broken -- you couldn't save that in the UI!). There are then 2 modules, one a submodule and one a separate project, which provide a DB backend and a Solr backend respectively. Each of these modules sets its backend into the index in a hook_install().

This works smoothly because there is only one index, and its name is known. In Finders, with multiple indexes, we don't have that simplicity!

We came up with the idea of adding more to the node type form: a way of saying either 'Yes, give me a sane default backend' or 'No, I'll set a backend myself after I've saved this form'. The initial idea was that this form alteration would be done by both the DB and the Solr modules.

However, I think we can simplify this a bit more:

• the DB and the Solr module provide backends, and in their third party settings, set a value localgov_finders_backend = TRUE.
• localgov_finders_form_node_type_form_alter() loads backends and offers those which have that setting as potential options.

Argh though where this breaks down is that localgov_finders_form_node_type_form_alter() only saves the node type. Stuffing that backend ID into the node type feels wrong :/

[joachim-n]

I filed this in the wrong project ... :/

[joachim-n]

https://github.com/localgovdrupal/localgov_finders/issues/7