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
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | 1760592-27-D6.patch | 3.4 KB | pwolanin |
| #22 | 1760592-22.patch | 4.32 KB | pwolanin |
| #19 | 1760592-19.patch | 3.32 KB | pwolanin |
| #18 | 1760592-18.patch | 3.23 KB | pwolanin |
| #9 | default-environment-1760592-9.patch | 719 bytes | cpliakas |
Comments
Comment #1
cpliakas commented+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
Comment #2
cpliakas commentedAttached 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.
Comment #4
johnennew commentedHi 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.
Comment #5
johnennew commentedHi 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
Comment #6
cpliakas commentedThanks for reporting back, John! Now let's see if we can fix the tests.
Comment #7
nick_vhjust 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.
Comment #8
cpliakas commentedNick,
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
Comment #9
cpliakas commentedLooks 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.
Comment #10
johnennew commentedI 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.
Comment #11
amanire commentedPatch #9 worked for me.
Comment #12
paulmckibbenPatch #9 works for me as well. Thanks!
Comment #13
MadhuraVadvalkar commentedWas observing the same issue, Applying the patch worked for me! thx
Comment #14
pwolanin commentedThere is a somewhat-related bug that the search tab shows up even if apachesolr is disabled in the core search UI.
Comment #15
cpliakas commentedIs this due to the patch, caused by the same root problem this patch is trying to address, or something else?
Comment #16
pwolanin commentedI think it's related to the logic in function apachesolr_search_menu_alter(), so it should be solved in a different issue.
Comment #17
cpliakas commentedGotcha. Thanks!
Comment #18
pwolanin commentedHere's a larger patch that adds a new hook and set the correct value for the core search page.
Comment #19
pwolanin commentedmissed some doxygen.
Comment #20
cpliakas commentedExcellent! Definitely more robust. Will test shortly.
Comment #21
cpliakas commentedThis 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
Comment #22
pwolanin commentedMaybe we should throw in an API-level prevention for deleting the current default env? Or is that bad API design?
Comment #23
cpliakas commentedI'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
Comment #24
pwolanin commentedok, let's make a separate issue for API change
Comment #25
cpliakas commentedSounds good to me. Re-RTBCing the the patch at #1760592-19: core_search page does not use the current default search enviroment.
Comment #26
pwolanin commentedcommited #19
Comment #27
pwolanin commentedquick backport - not tested
Comment #28
nick_vhShould 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?
Comment #29
cpliakas commentedI 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.
Comment #30
pwolanin commentedSeems to work as expected. committed.
Comment #32
mototribe commentedI 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?