Add an option to select which search page facets link to when displayed on non-search pages

The attached patch is my first attempt at adding the suggested functionality.

To summarize, the code finds all paths that are associated with the environment and exposes them as radio buttons. If there are no search pages associated with an environment, the settings are not displayed. A wrapper function was added to get the path from the selected search page while checking the sanity of the value. If it is not sane, for example the administrator moves the page to another environment, then the facets are not displayed. I also grouped the settings under the "apachesolr_variables" element to simplify the apachesolr_search_facetapi_realm_settings_form_submit() function.

Fixed some comments.

Search fail. Since this one has patch history, I will close the other one.

Thanks for testing, and brainstorming is good!

The reason why I added it under the facet configuration page is because architecturally facet configurations are tied to environments. To me it would be more confusing to split facet configurations out between the environment-specific administrative page and search page-specific administrative pages. The way the UI works in the attached patch the user can say, "This is my facet configuration, these are the non-search pages that I want my facets to display on, and this is the search page I want them to link to." all on the same administrative page. Otherwise they would have to configure the facets, click on the search pages tab, click on the search page, then expand the advanced settings tab. To me that is too much clicking required to configure settings that are deeply coupled, and it would also hide the functionality which based on my issue queue is a fairly common request.

Another issue I see is that we are only checking to display facets related to the default environment. I still don't really agree with this and think we should be checking all environments, bu regardless this could cause some confusion where settings are active on search pages that don't belong to the default environment. This is more of a minor issue because we could hide the configuration for pages tied to non-default environments, however I also think that it would be confusing that the non-search page settings are active on some search pages but not on others.

Just my $0.02,
Chris

I still strongly disagree with this approach from a UX standpoint. If you can only link the facets to one search page, then why are we providing this option on every search page? How do we specify which search page's configuration is active? I'll re-roll a patch taking the approach in #8 if that is consensus, but I do strongly urge that we walk through a site builder's use case to make sure we aren't introducing too much confusion.

If we stick with facet configuration you'd likely have to never change environment because you would loose those settings?

Well, you could change the environment, but you would have to select another search page that facets would link to otherwise they would no longer display. There really isn't a good way around this other than displaying a message after changing an environment of the selected page saying "Hey... go here to choose another search page.".

On the other hand, I do see potential problems when someone tries to redirect a certain block to two different search pages.

This is the part that I have the most problems with from a UX standpoint. Users will think that it is a valid option to have facets on page /foo link to page 1 and facets on page /bar link to page 2. This isn't possible given that facets and all of the non-search page settings are tied to an environment. This limitation is made clear and there is no confusion with the UI in #3 since it hits you over the head that you can only link to one search page.

I guess we could rearchitect the solution to store the settings per-search page as opposed to per-environment in order to accomodate this? The down side is that we would have to loop over all search page configs in hook_init() and stop on the first one we encounter. Not really a big fan of that, though, because it seems like there is some guessing happening which could lead to inconsistency.

I'm not sure where that alternate location would be, but I am definitely open to exploring this. I want to take a step back so I can think about this more objectively. Like we discussed offline there is no magic bullet here, each option has its drawbacks.