You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a write up along with steps to recreate the issue with advanced search facets that I mentioned on the blacklight developers forum (I’m hesitant to call it a bug since there's a good change it's an issue with my particular configuration).
The “bug” is a little obscure. Under a particular configuration, when you enter the advanced search screen without having selected any facets prior to entering this screen, facets do not display on the advanced search form. However, if you select a facet prior to entering this screen, facets do display.
This issue goes away with a code change to the get_advanced_search facets on the advanced search plugin, by moving the code that populates search_context_params outside the “if clause” (more detail below), though I wouldn’t really propose this as a bug fix since it’s very configuration dependent and I think it may be causing other side effects.
Unfortunately, steps to recreate are a little involved, since they depend on a different solr configuration than the one that ships with the blacklight quickstart, though we can use the example solr installation that ships with 4.7.1.
(I got rid of everything else, since this is enough to reproduce the issue)
Start up the app
Under my_search
rails server
From the home page, click on “more options”
No facets will be displayed on the advanced search page
Return to the home page
limit your search to a category (facet)
and click on “more options”
Now you will see facets on the advanced search page
There is a code change that will force the facets to load on the advanced search page. I’m not convinced it’s the right approach here, but maybe it’ll help shed some light on why the facets weren’t building...
Override the get_advanced_search_facets method in advanced_controller
and move the code to build the search_context_params out of the if clause
...I did this by creating an advanced_search.rb file in the initializers and adding...
BlacklightAdvancedSearch::AdvancedController.module_eval do
def get_advanced_search_facets
search_context_params = {}
# We have a search context, need to fetch facets from within
# that context -- but we dont' want to search within any
# existing :q or ADVANCED facets, so we remove those params.
adv_keys = blacklight_config.search_fields.keys.map {|k| k.to_sym}
trimmed_params = params.reject do |k,v|
adv_keys.include?(k.to_sym) # the individual q params
end
trimmed_params.delete(:f_inclusive) # adv facets
search_context_params = solr_search_params(trimmed_params)
if (advanced_search_context.length > 0 )
...
Pulling the code to build search_context_params out of the if clause.
With this chance, the facets will show up on the advanced search page even if no facet was selected prior to linking to this page.
Note - Individual record links are also broken under this solr configuration, though this can be fixed by overriding solr_helper.rb as described in this blog post.
Here's a write up along with steps to recreate the issue with advanced search facets that I mentioned on the blacklight developers forum (I’m hesitant to call it a bug since there's a good change it's an issue with my particular configuration).
The “bug” is a little obscure. Under a particular configuration, when you enter the advanced search screen without having selected any facets prior to entering this screen, facets do not display on the advanced search form. However, if you select a facet prior to entering this screen, facets do display.
This issue goes away with a code change to the get_advanced_search facets on the advanced search plugin, by moving the code that populates search_context_params outside the “if clause” (more detail below), though I wouldn’t really propose this as a bug fix since it’s very configuration dependent and I think it may be causing other side effects.
Unfortunately, steps to recreate are a little involved, since they depend on a different solr configuration than the one that ships with the blacklight quickstart, though we can use the example solr installation that ships with 4.7.1.
create a new blacklight rails app using quickstart the “easy way” (which really is easy, thanks for writing it!)
rails new search_app -m https://raw.github.com/projectblacklight/blacklight/master/template.demo.rb
add the advanced search gem to Gemfile
gem 'blacklight_advanced_search', "~> 5.0"
and run bundle
and run the generator
rails generate blacklight_advanced_search
run the example configuration that ships with solr 4.7.0
(this is all taken from the solr tutorial at https://lucene.apache.org/solr/4_7_0/tutorial.html)
start the example solr within the solr-4.7.0 directory in /example
java -jar start.jar &
index some records in /example/exampledocs
java -jar post.jar *.xml
catalog_controller and advanced_controller
(I got rid of everything else, since this is enough to reproduce the issue)
Under my_search
rails server
No facets will be displayed on the advanced search page
limit your search to a category (facet)
and click on “more options”
Now you will see facets on the advanced search page
Override the get_advanced_search_facets method in advanced_controller
and move the code to build the search_context_params out of the if clause
...I did this by creating an advanced_search.rb file in the initializers and adding...
BlacklightAdvancedSearch::AdvancedController.module_eval do
def get_advanced_search_facets
Pulling the code to build search_context_params out of the if clause.
With this chance, the facets will show up on the advanced search page even if no facet was selected prior to linking to this page.
Note - Individual record links are also broken under this solr configuration, though this can be fixed by overriding solr_helper.rb as described in this blog post.
https://blogs.library.ucsf.edu/ckm/2014/03/11/working-with-blacklight-part-3-linking-to-your-solr-index/
The text was updated successfully, but these errors were encountered: