The edit search page for core_search is located at the url:
/admin/config/search/apachesolr/search-pages/core_search/edit

When you visit this page you are not permitted to change the search environment for core search and it displays the message:

"This page always uses the current default search environment"

However, this is not true and the core_search always defaults to the search environment with machine id solr regardless of what is set as the default on the following page:
/admin/config/search/apachesolr/settings

In a standardised dev / test / live enviroment with a different apache solr environment for each environment, I would like to be able to set the default environment via the settings.php conf value 'apachesolr_default_environment' have this select the default environment. This works for all settings except core_search page as far as I can tell.

Rgds,
John

Comments

cpliakas’s picture

Priority: Normal » Major
Status: Needs work » Active

+1.

Confirming this bug and upping the priority. If you add another environment, such as an Acquia Search connected environment or an A12 Find connected environment, you cannot use that service unless you create a separate search page that explicitly uses that environment.

As per the Status settings for an issue page, setting the status to "active" since there is no patch yet.

Thanks for reporting,
Chris

cpliakas’s picture

Status: Active » Needs review
StatusFileSize
new577 bytes

Attached is a patch that ensures the "core_search" pages uses the default environment, but I am thinking that we should also revisit #1635244: Move away from the concept of a "default environment"? since this is a bit confusing.

Status: Needs review » Needs work

The last submitted patch, default-environment-1760592-2.patch, failed testing.

johnennew’s picture

Hi cpliakas,

Thanks for looking into this. This appears to work - when you view the pages admin page it says it is using the default environment at:
admin/config/search/apachesolr/search-pages

But when you edit the core_search page, the greyed out dropdown still selects the solr item:
admin/config/search/apachesolr/search-pages/core_search/edit

If you do a search you'll get the apachesolr unavailable message (if there isn't an accessible apachesolr at the URL specified by the solr environment)

Oddly, saving the core_search page does then set the core_search environment to the default, despite the disabled dropdown pointing to solr:
admin/config/search/apachesolr/search-pages/core_search/edit

As I am building this site via an install profile, I really need it to set the core_search to the default environment immediately and I would expect this to be the default behaviour.

johnennew’s picture

Hi cpliakas,

My apologies, I had the default core_search page exported using features and it sets the default environment to solr after enabling the module.

This patch works fine for my issue.

This does mean of course that you can change the core_search environment from the default by setting its variables in its features exportable.

Kind regards,

John

cpliakas’s picture

Thanks for reporting back, John! Now let's see if we can fix the tests.

nick_vh’s picture

just to give you some insight - We explicitly did not want to make that editable because of
1) there is still a dependency on core search, which gets messy if the environment is not the default one (but I think that has been tackled now)
2) to make it easier for the user.

I do like the fact that this fields becomes open for all environments, it only makes more sense also. but we should check wether core search is a showstopper here.

cpliakas’s picture

Nick,

Understood. As the patch stands the field is still not editable, it just uses the default environment as the help text states. I am not thinking that core search will care which environment is being used, just as long as one is being used. I'll dig in to make 100% sure this is the case, and I will add some tests surrounding this as well.

Thanks,
Chris

cpliakas’s picture

Status: Needs work » Needs review
StatusFileSize
new719 bytes

Looks like during tests, the "core_search" page isn't defined which is what was causing the errors. Attached patch will (hopefully) make the testing bot happy.

johnennew’s picture

Status: Needs review » Reviewed & tested by the community

I have been testing deployment of a new site builds with the patch in #9 for over a week now and it appears to work fine.

amanire’s picture

Patch #9 worked for me.

paulmckibben’s picture

Patch #9 works for me as well. Thanks!

MadhuraVadvalkar’s picture

Was observing the same issue, Applying the patch worked for me! thx

pwolanin’s picture

There is a somewhat-related bug that the search tab shows up even if apachesolr is disabled in the core search UI.

cpliakas’s picture

Is this due to the patch, caused by the same root problem this patch is trying to address, or something else?

pwolanin’s picture

I think it's related to the logic in function apachesolr_search_menu_alter(), so it should be solved in a different issue.

cpliakas’s picture

Gotcha. Thanks!

pwolanin’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new3.23 KB

Here's a larger patch that adds a new hook and set the correct value for the core search page.

pwolanin’s picture

StatusFileSize
new3.32 KB

missed some doxygen.

cpliakas’s picture

Excellent! Definitely more robust. Will test shortly.

cpliakas’s picture

Status: Needs review » Reviewed & tested by the community

This works as designed, so marking as RTBC.

There is still the case with things like Acquia Search, where the module will delete the default environment leaving you with no default. However, that is probably a separate issue but just wanted to highlight it here as well.

Thanks!
Chris

pwolanin’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new4.32 KB

Maybe we should throw in an API-level prevention for deleting the current default env? Or is that bad API design?

cpliakas’s picture

I'm not sure. Thinking about this further I'm not positive that the "no default environment" scenario is actually an issue more of than a point of confusion. So maybe we should separate the API-level discussion into a separate task so we can at least roll out a fix more quickly? If we want to tackle that here, too, we can. I am fin with either approach.

Thanks,
Chris

pwolanin’s picture

ok, let's make a separate issue for API change

cpliakas’s picture

Status: Needs review » Reviewed & tested by the community
pwolanin’s picture

Version: 7.x-1.x-dev » 6.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

commited #19

pwolanin’s picture

Status: Patch (to be ported) » Needs review
StatusFileSize
new3.4 KB

quick backport - not tested

nick_vh’s picture

Should we consider the default search page, if it is core_search or not, as a page that also should be always linked to the default env?

cpliakas’s picture

I would say no, definitely not in this issue, and probably not in general. This change could potentially break people's configurations, since it would change the expected environment if their default search page was not set to use the default search environment.

pwolanin’s picture

Status: Needs review » Fixed

Seems to work as expected. committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

mototribe’s picture

I just upgraded to 7.x-1.1 and added a 2nd search page "solr search" with path "keyword" and made it the default.
I cleared the caches and when using the search box it still goes to the default search url at "search/sites".
What did I miss?