projectblacklight / blacklight_advanced_search Goto Github PK

The latest version 7.0.0 does not work as expected with blacklight 7.29, the "More options" button does not appear...

One has to add:

config.advanced_search[:enabled] = true

to catalog_controller.

This is already in current main https://github.com/projectblacklight/blacklight_advanced_search/blame/3a1909fdf91cbe67a8ddab92bc329691de093e1a/lib/generators/blacklight_advanced_search/install_generator.rb#L18 but if the major version of plugin/blacklight should indicate compatibility maybe this should get to some 7.x release?

Rubocop errors unless it is pinned to version 0.46, along with rubocop-rspec pinned to 1.8.

The CI tests are failing when using Ruby 3.1 with

The asset 'application.js' was not found in the load path.

So far I have not been able to reproduce the issue locally using the same version of Ruby.

I noticed a small issue with the way that search context is passed to Advanced Search. I described it at psu-libraries/psulib_blacklight#362 (comment)

To reproduce:

1. Do a search
2. Click an item
3. Click advanced search link
4. Without performing another search, go to another record directly. For example, paste in the URL that resulted from step 2.
5. Error

Unfortunately I don't have a fix besides dropping search context to Advanced Search, which I can say for our use case anyway is desirable.

Stack trace copied here too for convenience

[2019-06-18T14:00:55.977879 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Started GET "/catalog/1128228" for 128.118.152.108 at 2019-06-18 14:00:55 -0400
I, [2019-06-18T14:00:55.980101 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Processing by CatalogController#show as HTML
I, [2019-06-18T14:00:55.980245 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Parameters: {"id"=>"1128228"}
D, [2019-06-18T14:00:55.990413 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Solr query: get get {:qt=>nil, :ids=>"1128228"}
D, [2019-06-18T14:00:55.990549 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Solr fetch (5.1ms)
D, [2019-06-18T14:00:55.993981 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Search Load (0.6ms)  SELECT  `searches`.* FROM `searches` WHERE `searches`.`id` IN (3744, 3743, 3741, 3740, 3739, 3738, 3718, 3666, 3650, 3649, 3612, 3611, 3610, 3586, 3585, 3579) AND `searches`.`id` = 3744 ORDER BY updated_at desc LIMIT 1
D, [2019-06-18T14:00:56.717115 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Solr query: get select {"qt"=>nil, "facet.field"=>["access_facet", "format", "{!ex=campus_facet_single}campus_facet", "{!ex=library_facet_single}library_facet", "{!ex=up_library_facet_single}up_library_facet", "pub_date_itsi", "language_facet", "subject_topic_facet", "genre_facet", "media_type_facet", "lc_1letter_facet", "lc_rest_facet"], "facet.query"=>[], "facet.pivot"=>["lc_1letter_facet,lc_rest_facet"], "fq"=>[], "hl.fl"=>[], "rows"=>2, "facet"=>false, "f.campus_facet.facet.sort"=>"index", "f.campus_facet.facet.limit"=>-1, "f.library_facet.facet.sort"=>"index", "f.library_facet.facet.limit"=>-1, "f.up_library_facet.facet.sort"=>"index", "f.up_library_facet.facet.limit"=>-1, "f.language_facet.facet.limit"=>11, "f.subject_topic_facet.facet.limit"=>21, "f.genre_facet.facet.limit"=>21, "f.media_type_facet.facet.limit"=>21, "f.lc_1letter_facet.facet.sort"=>"index", "f.lc_rest_facet.facet.sort"=>"index", "sort"=>"score desc, pub_date_itsi desc, title_sort asc", "stats"=>"true", "stats.field"=>["pub_date_itsi"], "fl"=>"id"}
D, [2019-06-18T14:00:56.717250 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Solr fetch (722.4ms)
I, [2019-06-18T14:00:56.718171 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendering catalog/show.html.erb within layouts/blacklight
I, [2019-06-18T14:00:56.721927 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/_show_header_default.html.erb (0.3ms)
I, [2019-06-18T14:00:56.726045 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/_show_top_fields.html.erb (3.9ms)
I, [2019-06-18T14:00:56.726361 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/_show_availability.html.erb (0.1ms)
D, [2019-06-18T14:00:56.726796 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Looking for document partial show_list_book
D, [2019-06-18T14:00:56.727116 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Looking for document partial show_list_default
D, [2019-06-18T14:00:56.727380 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Looking for document partial show_book
D, [2019-06-18T14:00:56.727560 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Looking for document partial show_default
I, [2019-06-18T14:00:56.736123 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/_marc_record_details.html.erb (0.3ms)
I, [2019-06-18T14:00:56.746183 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/_show_main_content.html.erb (27.7ms)
I, [2019-06-18T14:00:56.746395 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/show.html.erb within layouts/blacklight (28.1ms)
I, [2019-06-18T14:00:56.746719 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendering layouts/blacklight/base.html.erb
I, [2019-06-18T14:00:56.748113 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered shared/_announcement.html.erb (0.2ms)
D, [2019-06-18T14:00:56.750041 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   User Load (0.5ms)  SELECT  `users`.* FROM `users` WHERE `users`.`email` = '[email protected]' LIMIT 1
D, [2019-06-18T14:00:56.752121 #2666] DEBUG -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]    (0.3ms)  SELECT COUNT(*) FROM `bookmarks` WHERE `bookmarks`.`user_id` = 771 AND `bookmarks`.`user_type` = 'User'
I, [2019-06-18T14:00:56.752330 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered vendor/bundle/ruby/2.5.0/bundler/gems/blacklight-39d676481858/app/views/blacklight/nav/_bookmark.html.erb (1.7ms)
I, [2019-06-18T14:00:56.752748 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered shared/_user_util_links.html.erb (4.0ms)
I, [2019-06-18T14:00:56.757085 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered catalog/_search_form.html.erb (3.9ms)
I, [2019-06-18T14:00:56.757209 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered shared/_header_navbar.html.erb (8.9ms)
I, [2019-06-18T14:00:56.757543 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered vendor/bundle/ruby/2.5.0/bundler/gems/blacklight-39d676481858/app/views/shared/_flash_msg.html.erb (0.1ms)
I, [2019-06-18T14:00:56.758724 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]   Rendered layouts/blacklight/base.html.erb (11.9ms)
I, [2019-06-18T14:00:56.758973 #2666]  INFO -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] Completed 500 Internal Server Error in 779ms (ActiveRecord: 1.4ms)
F, [2019-06-18T14:00:56.759827 #2666] FATAL -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]
F, [2019-06-18T14:00:56.759897 #2666] FATAL -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] ActionView::Template::Error (No route matches {:action=>"index", :controller=>"advanced", :id=>"27043523", :page=>1}):
F, [2019-06-18T14:00:56.760069 #2666] FATAL -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     30:         <% if @search_context %>
[0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     31:             <% if current_search_session %>
[0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     32:                 <div id="appliedParams" class="col-auto">
[0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     33:                   <%= link_back_to_catalog class: 'btn btn-outline-secondary btn-sm' %>
[0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     34:                 </div>
[0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     35:             <% end %>
[0333aef5-b671-4743-b3ba-ae5fadd0cfb4]     36:
F, [2019-06-18T14:00:56.760115 #2666] FATAL -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4]
F, [2019-06-18T14:00:56.760157 #2666] FATAL -- : [0333aef5-b671-4743-b3ba-ae5fadd0cfb4] app/views/layouts/blacklight/base.html.erb:33:in `_app_views_layouts_blacklight_base_html_erb__2452668260066727727_69883618903300'

I've noticed that if I have a search field with a filter using ${var} syntax (like demo.blacklight.com),
blacklight advanced search throws an error for queries with multiple fields.

400 Bad Request
Error: 'org.apache.solr.search.SyntaxError: Expected identifier at pos 68 str=\'{!dismax qf=

The generated query looks like this:

q=_query_:"{!dismax }test" OR _query_:"{!dismax qf=${title_qf} pf=${title_pf}}test"

If I use $var syntax (like in the advanced_search readme), it works fine.

I'm not sure what the significance of $var vs ${var} is. Is this an dismax vs edismax thing?
Will there be support for advanced search with ${var} syntax?

edismax supports wildcarding (e.g. "Blacklig*") but dismax doesn't. Can we change this line:

https://github.com/projectblacklight/blacklight_advanced_search/blob/master/lib/parsing_nesting/tree.rb#L188

to use edismax instead?

include BlacklightAdvancedSearch::ParseBasicQ in class CatalogController yields a problem
when staring up server with: rails s
gives an error: gems/blacklight_advanced_search-5.1.1/lib/blacklight_advanced_search/parse_basic_q.rb:16:in block in <module:ParseBasicQ>': undefined methodsolr_search_params_logic' for CatalogController:Class (NoMethodError)

blacklight (5.7.1)
rails 4.1
blacklight_advanced_search (5.1.1)

Inside my configure_blacklight do |config| block, I have added:

    config.advanced_search = {
        :form_solr_parameters => {
            "facet.field" => ["orgid", "noteType"]
        }
    }

However, the /advanced view is displaying the default facets from the Solr search requestHandler. Furthermore, the log output from Solr that corresponds to loading the advanced search is:

INFO  org.apache.solr.core.SolrCore  ? [collection1] webapp=/solr path=/select params={wt=ruby} hits=1000000 status=0 QTime=49 

This indicates that nothing is being changed by setting :form_solr_parameters in config.advanced_search. Am I missing something or is this really not working? Adding a :qt that doesn't exist to the config.advanced_search does produce an error, so the variable is being set.

I'm using this gem on a couple GeoBlacklight 2+ / Blacklight 7+ installs. The gem's generator adds a saved_searches_controller.rb file referencing Blacklight::SavedSearches:
https://github.com/projectblacklight/blacklight_advanced_search/blob/master/lib/generators/blacklight_advanced_search/templates/saved_searches_controller.rb

I believe Blacklight::SavedSearches was removed in BL 7... so for this gem to run correctly, you have to delete the saved_searches_controller.rb file the generator creates like so:
psu-libraries/psulib_blacklight#237

Hope this helps someone!

Trying to wrap my head around what's going on with the various pieces of code, and how to do a sensible release plan. Appreciate feedback, esp from @cbeer who is committer on much of the not-yet-released code.

State of the code

The current latest blacklight_advanced_search release is 2.1.1 from July 29 2013. That is one day before the release of Blacklight 4.3.0. The gemspec for 2.1.1 says "blacklight", "~> 4.0", which says it expects to work with all Blacklight 4.x, but who knows if that's actually true.

There are three outstanding pull requests in the github issues here. One of them (#12) says it's about removing deprecated uses, but also changes the gemspec to require at least Blacklight 4.7.

There's also a blacklight-4.7+ branch here in blacklight_advanced_search, which does have commits that are not in master, and which I think is not represented in any pull requests.

There's also a more recent blacklight5 branch, also apparently not merged into master or represented in any PR's.

My plan

• 1: Last Blacklight 4.x release
  • Try to merge all outstanding pull requests into master.
  • Try to merge existing blacklight-4.7+ branch into master.
  • Do some code review on each one, don't just blindly merge
  • Give up on ones I have trouble with
  • Release a blacklight_advanced_search 2.2, which is for Blacklight 4.7 and theoretical future 4.x Last 4.x release, which requires at least 4.7, cause that's what the existing pull requests/branches want, although I'm not certain why.
• 2: blacklight5 release
  • then, merge blacklight5 branch into master.
  • release a blacklight_advanced_search 5.x, with gemspec set to expect to work with any Blacklight 5.x. Yep, major version number sync, 5=5.

Good?

If anyone has any suggestions or sees any problems, and especially if you have information or understanding of what's going on that I am missing that suggests modifying this plan, please let me know!

Working on a new GeoBlacklight install for UW-Milwaukee. We're seeing advanced search constraint selections rendered twice in the application:

I haven't made a lot of customizations here, beyond branding/theming, so the application is pretty vanilla:

• Rails 7.0.4.2
• Solr 9.1.1
• Blacklight 7.33.1
• GeoBlacklight 4.0.0
• Blacklight Advanced Search 7.0.0

Codebase is here:
https://github.com/UWM-Libraries/GeoDiscovery/tree/feature/advanced-search

Looks like the BTAA Geoportal also has a similar issue, although there only the constraints render twice, and things are not duplicated in the facets.

• Rails 6.1.7
• Solr 8.1.1
• Blacklight 7.30.0
• GeoBlacklight 4.0.0
• Blacklight Advanced Search 7.0.0

I'll dive into the issue further during the GBL Winter community sprint the week of Feb. 27th, but would appreciate any insights beforehand if this rings a bell for anyone.

The check_box_tag in advanced search uses the value of the facet to create an id. If the value includes a period, then trying to use that id as a string for a jQuery search interprets the period as a class. Better to sanitize the value in some way before turning it into a symbol.

This causes problems with Jonathan's new javascript for advanced search facets display. For instance if you select "Milton S. Eisenhower Library" in the Library Location facet then it becomes impossible to deselect that value.

You can see where this happens here:

https://github.com/projectblacklight/blacklight_advanced_search/blob/master/app/views/advanced/_facet_limit.html.erb

I was already overriding this template so I just changed the line to replace all periods with double dashes:

<%= check_box_tag "f_inclusive[#{solr_field}][#{item.value.gsub('.','--').to_sym}]", 1, facet_value_checked?(solr_field, item.value)%> <%= label_tag "f_inclusive_#{solr_field}[#{item.value.to_sym}]", h(item.value) %> (<%= format_num item.hits %>)

If you want that fix then I can apply it, but I wonder if there aren't other characters that ought to be cleaned out of a value before using it as an id so we'd want to move this logic into some kind of helper rather than put more of that string cleaning in the view?

Using solr 7.2.1. To get the correct and matching search results between our dropdown on main page and advanced search I am using solr_parameters rather than solr_local_parameters in config.add_search_field.

config.add_search_field 'default', label: 'All Fields' do |field| field.include_in_advanced_search = false field.solr_parameters = {df: 'default'} end

If there is an odd character entered in the search box or on the advanced search page (different field that is included) then I get a 400 error from solr. For example if I type 4081]

{:status=>400, :headers=>{"cache-control"=>["no-cache, no-store"], "pragma"=>["no-cache"], "expires"=>["Sat, 01 Jan 2000 01:00:00 GMT"], "last-modified"=>["Wed, 15 Aug 2018 13:56:39 GMT"], "etag"=>["\"1653ddfc53e\""], "content-type"=>["text/plain;charset=utf-8"], "connection"=>["close"]}, :body=>"{\n 'responseHeader'=>{\n 'status'=>400,\n 'QTime'=>1,\n 'params'=>{\n 'f.related_people_facet.facet.limit'=>'11',\n 'f.book_genres_facets.facet.mincount'=>'1',\n 'facet.field'=>['content_type',\n 'related_people_facet',\n 'poem_themes_facets',\n 'poem_genres_facets',\n 'book_genres_facets',\n 'gender',\n 'date_facet'],\n 'qt'=>'/browse',\n 'f.poem_themes_facets.facet.limit'=>'11',\n 'f.date_facet.facet.mincount'=>'1',\n 'fq'=>'is_displayed_content_type:1',\n 'f.book_genres_facets.facet.limit'=>'11',\n 'sort'=>'score desc',\n 'rows'=>'10',\n 'f.content_type.facet.mincount'=>'1',\n 'f.poem_themes_facets.facet.mincount'=>'1',\n 'f.gender.facet.mincount'=>'1',\n 'f.poem_genres_facets.facet.limit'=>'11',\n 'q'=>'4081]',\n 'qf'=>'default',\n 'f.related_people_facet.facet.mincount'=>'1',\n 'f.poem_genres_facets.facet.mincount'=>'1',\n 'stats'=>'true',\n 'wt'=>'ruby',\n 'facet'=>'true',\n 'stats.field'=>'date_facet'}},\n 'error'=>{\n 'metadata'=>[\n 'error-class','org.apache.solr.common.SolrException',\n 'root-error-class','org.apache.solr.parser.TokenMgrError'],\n 'msg'=>'org.apache.solr.search.SyntaxError: Cannot parse \\'4081]\\': Lexical error at line 1, column 6. Encountered: <EOF> after : \"\"',\n 'code'=>400}}\n"}

if I type "4081]" or if I use solr_local_parameters then I do not get this error.
I need to use solr_parameters so that the results returned are correct (we have edismax as default search).
Is there a problem with the quotes when using solr_parameters?
Do I need to tell users to use the quotes?

I'm getting

undefined method `search_results' for ...

on a site that I have upgraded to BL-7.

Using the latest commit (9c23f0e) along with Blacklight 7.0.1, I hit this error when attempting to do an advanced search of only choosing one format facet and nothing else. NameError in Catalog#index

To fix this I did the following.

--- a/app/views/blacklight_advanced_search/_facet_limit.html.erb
+++ b/app/views/blacklight_advanced_search/_facet_limit.html.erb
@@ -2,15 +2,15 @@
   <div class="inclusive_or well">
     <h4>Any of:</h4>
     <ul class="list-unstyled facet-values">
-    <% advanced_query.filters[solr_field].each do |value| %>
+      <% advanced_query.filters.each do |solr_field, value| %>
         <li>
-            <span class="selected"><%= h(value) %></span>
-            <%= link_to(remove_advanced_facet_param(solr_field, value, params), :class => "remove") do %>
-                <span class="glyphicon glyphicon-remove"></span><span class="sr-only">[remove]</span>
-            <% end %>
+          <span class="selected"><%= h(value) %></span>
+          <%= link_to(remove_advanced_facet_param(solr_field, value, params), :class => "remove") do %>
+            <span class="glyphicon glyphicon-remove"></span><span class="sr-only">[remove]</span>
+          <% end %>
         </li>
-    <% end %>
+      <% end %>
     </ul>
   </div>

I'll add thought that I just overrode the partial anyway because I thought it looked confusing

<div class="advanced_facet_limit">
  <%= render_facet_limit display_facet, :layout => nil, :partial => advanced_search_facet_partial_name(display_facet) %>
</div>

The README states that "versions 5.x of Advanced Search plugin should work with Blacklight >= 5.1 and < 6". However, version 5.1.4 of the gem requires blacklight ~> 5.10.

The current method signature

def add_advanced_search_to_solr(solr_parameters)

I'm running into a situation where it would be nice to be able to transform the params that this function uses when it creates it's initial query:

 advanced_query = BlacklightAdvancedSearch::QueryParser.new(blacklight_params, self.blacklight_config)

To do what I want I am left with two choices, either override this function which I would prefer not to maintain, or override blackligh_param which seems like overkill.

Since the behavior of this method depends so much on what blacklight_params are, maybe it makes total sense to pass that in as a parameter. The method would be easier to understand and to use without overriding.

If you create a new rails application and add both blacklight and blacklight_advanced_search to the Gemfile, when you go to generate blacklight, you get an error from blacklight_advanced_search when it tries to initialize:

md-20015348:blacklight_test chris_beer$ rails generate blacklight
/Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/blacklight_advanced_search-1.1.2/lib/blacklight_advanced_search.rb:46:in `config_defaults': You have a nil object when you didn't expect it! (NoMethodError)
You might have expected an instance of Array.
The error occurred while evaluating nil.find_all
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/blacklight_advanced_search-1.1.2/lib/blacklight_advanced_search.rb:18:in `init'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/blacklight_advanced_search-1.1.2/lib/blacklight_advanced_search/engine.rb:11:in `block in <class:Engine>'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/activesupport-3.1.3/lib/active_support/lazy_load_hooks.rb:34:in `call'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/activesupport-3.1.3/lib/active_support/lazy_load_hooks.rb:34:in `execute_hook'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/activesupport-3.1.3/lib/active_support/lazy_load_hooks.rb:43:in `block in run_load_hooks'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/activesupport-3.1.3/lib/active_support/lazy_load_hooks.rb:42:in `each'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/activesupport-3.1.3/lib/active_support/lazy_load_hooks.rb:42:in `run_load_hooks'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/application/finisher.rb:56:in `block in <module:Finisher>'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/initializable.rb:30:in `instance_exec'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/initializable.rb:30:in `run'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/initializable.rb:55:in `block in run_initializers'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/initializable.rb:54:in `each'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/initializable.rb:54:in `run_initializers'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/application.rb:96:in `initialize!'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/railtie/configurable.rb:30:in `method_missing'
    from /Volumes/Scratch/blacklight_test/config/environment.rb:5:in `<top (required)>'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/application.rb:83:in `require'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/application.rb:83:in `require_environment!'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight-test/gems/railties-3.1.3/lib/rails/commands.rb:22:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

I just install the advanced search plugin and this error happens when I try to make some search

I have :qt => 'select' in my config.default_solr_params, but when I go to /advanced, I see that solr is getting hit with qt=search. Shouldn't the advanced search be using the qt that I have defined in the Blacklight catalog_controller default_solr_params?

blacklight (5.4.0)
blacklight_advanced_search (5.1.0)

This affects the blacklight5 branch:

Visit advanced_search_path
Enter a search term in any of the text boxes
Select a facet using one of the checkboxes
Click "Search"
I get "undefined local variable or method `facet_field_labels'"

I can search multiple text fields, such as title, name, subject, or any of the other ones I've defined. It just doesn't like adding in facets to the mix.

So we’re getting a failure on from blacklight_advanced_search whenever we search anything with empty parens in it like “()” as the smallest case example. Anyone else see this… We are on the latest blacklight_advanced_search gem but we suspect issue goes back to other versions….
The error is
NoMethodError: undefined method `collect' for "()"@158:Parslet::Slice
and it’s getting thrown here

[GEM_ROOT]/bundler/gems/blacklight_advanced_search-9c23f0e9aad6/lib/parsing_nesting/tree.rb:40:in `to_node_tree'
38     elsif tree.is_a? Hash
39       if list = tree[:list]
40         List.new(list.collect { |i| to_node_tree(i, query_parser) }, query_parser)
41       elsif tree.has_key?(:and_list)
42         AndList.new(tree[:and_list].collect { |i| to_node_tree(i, query_parser) }, query_parser)```

My CatalogController uses I18n like this:

      config.add_facet_field 'tag_t', label: t('myapp.facet.tag'), limit: 5

This works fine in regular Blacklight. When I add advanced search, the to_prepare block (https://github.com/projectblacklight/blacklight_advanced_search/blob/master/lib/blacklight_advanced_search/engine.rb#L11-L21) causes CatalogController to load before Rails has a chance to initialize the i18n paths and my app shows "Missing Translation" errors.

We get a lot of Parslet::ParseFailed errors thrown from crawlers putting random input into the adv. search form. Should BlacklightAdvancedSearch rescue from this error or should it be up to the application to make a determination of what they would like to do?

Calling ParsingNesting::Tree::Node.to_query() with a hash containing a value that is not a string and contains a space in its to_s representation causes an error.
ParsingNesting::Tree::Node.build_local_params attempts to wrap the value using "'" + v + "'". It could use "'#{v}'" to properly handle non-string values, such as arrays.

When I am on the advanced search page
And I enter terms into the advanced search fields and click 'Search'
I should see the advanced field search constraints in the page title in the browser window

Blacklight::CatalogHelperBehavior#render_search_to_page_title (from projectblacklight/blacklight@47eab51) adds functionality to display search constraints in the page title on catalog#index views. However, advanced search constraints are not displayed, since there is no provision in that method to display them.

Methods could perhaps be added to BlacklightAdvancedSearch::RenderConstraintsOverride to add functionality to include advanced search constraints in the page title?

When the user query search from the advanced search with facet/s selected he cannot deselect them from the facets side bar on the results page. when he tries to click on the 'x' button the page goes to refresh and nothing happens.

Invocations like:

describe "whatever" do 
   include BlacklightAdvancedSearch::FilterParser
...

are failing to properly encapsulate the inclusion. Injecting everything into the rspec example is messy. Also the appearance of affecting only that describe block is misleading.

Due to this block causing CatalogController to load before the I18n initializers have run:
https://github.com/projectblacklight/blacklight_advanced_search/blob/master/lib/blacklight_advanced_search/engine.rb#L16-L21

This is the same as projectblacklight/blacklight_range_limit#41 but in the AdvanceSearch this time.

When translating facet constraints to solr query the conversion doesn't use solr cache right!

the request url contains:
&f_inclusive[pub_date][2008]&f_inclusive[pub_date][1976]
is translate into:
&fq=pub_date:("2008"+OR++"1976")
which is not good for cahcing, should be translated into:
&fq=pub_date:2008&fq=pub_date:1976

the second conversion make use of each condition separately in the cache

The corresponding code can be found in filter_parser.rb under "generate_solr_fq" method.

The documentation for customizing facets on the advanced search view given in the Readme isn't very useful because the destination for the snippet is not explained. I tried placing an appropriately adapted version of the Readme snippet in my catalog_controler.rb under configure_blacklight do |config|, but that broke everything. Where is this configuration supposed to be added to an app?

See: https://groups.google.com/d/msg/blacklight-development/tVKCjDqGQVA/8HioW15kRiIJ

I check out current master at 03f8af4.

I run bundle install, then bundle exec rake, to try to run tests.

It looks like it's doing some things to download and install a jetty. Then I get:

DEPRECATION WARNING: RSolr should be in your gemfile. Blacklight 6.0 will not load rsolr by default. (called from <module:Blacklight> at /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/solr_repository.rb:2)
DEPRECATION WARNING: Your application is missing the SearchBuilder. Have you run `rails generate blacklight:search_builder`? Falling back to Blacklight::Solr::SearchBuilder. (called from locate_search_builder_class at /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:225)
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight.rb:97:in `blacklight_yml': You are missing a configuration file: /Users/jrochkind/code/blacklight_advanced_search/spec/internal/config/blacklight.yml. Have you run "rails generate blacklight:install"? (RuntimeError)
    from /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight.rb:82:in `connection_config'
    from /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:217:in `connection_config'
    from /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/utils.rb:37:in `[]'
# ...
DEPRECATION WARNING: RSolr should be in your gemfile. Blacklight 6.0 will not load rsolr by default. (called from <module:Blacklight> at /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/solr_repository.rb:2)
DEPRECATION WARNING: Your application is missing the SearchBuilder. Have you run `rails generate blacklight:search_builder`? Falling back to Blacklight::Solr::SearchBuilder. (called from locate_search_builder_class at /Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:225)
rake aborted!
You are missing a configuration file: /Users/jrochkind/code/blacklight_advanced_search/spec/internal/config/blacklight.yml. Have you run "rails generate blacklight:install"?
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight.rb:97:in `blacklight_yml'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight.rb:82:in `connection_config'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:217:in `connection_config'
# ...

Then more bundle install output, so I'm not sure if that stopped it or not? Then a bunch of solr/jetty log lines. Then another set of deprecations, followed by:

NameError: uninitialized constant SolrDocument
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:186:in `document_model'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/utils.rb:37:in `[]'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:181:in `block in initialize_default_values!'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:180:in `each'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:180:in `initialize_default_values!'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight/configuration.rb:172:in `initialize'
/Users/jrochkind/.gem/ruby/1.9.3/gems/blacklight-5.13.0/lib/blacklight.rb:72:in `new'

That one seems to finally kill it with, a Error running fixtures. Specs were not run.

Is there a way to run specs locally in current master?

I had to manually unset pivot facets from the blacklight advanced request parameters. I did this by setting pivot_facet to ''. I'm a) not sure that it is expected behavior that pivot facets can't be excluded the same way as other facets and b) not sure the way I excluded it is the best way (though it worked).

I believe this is a partially known issue too.

If this is expected behavior, I think that it'd be useful to add a note to the README on pivot facets.

Hi all,

When I add the following lines into my catalog_controller, the @documents variable that is passed to my citation view and the bookmarks display suddenly includes every single document in my solr index(!) This had not been a problem with Blacklight and advanced_search 5.x; only ran into it when I upgraded both to 6.x. I am using rails 4.2, by the way.

        config.advanced_search = {
          :form_solr_parameters => {
            "facet.field" => ["format", "language_facet"],
            "facet.limit" => -1, # return all facet values
            "facet.sort" => "index" # sort by byte order of values
          }
        }

Steps to reproduce:

1. rails _4.2.5_ new not_working
2. cd not_working
3. Add gem "blacklight_advanced_search", '~> 6.0' and gem 'blacklight', '~>6.6' to your Gemfile.
4. rails generate blacklight_advanced_search and rails generate blacklight:install --devise
5. rake db:migrate
6. Add those lines (or something similar; I have tried different values for all of the facet.* configurations) to catalog controller.
7. Try visiting bookmarks, where you will note that every single document in the index is suddenly visible in your bookmarks!
8. Try going to localhost:3000/catalog/some_document_id/citation. You'll not that it returns citations for the first 10 documents in your index, rather than the requested document.

Any suggestions? Thanks in advance for your help!

Bad check at:
https://github.com/projectblacklight/blacklight_advanced_search/blob/master/lib/blacklight_advanced_search.rb#L30

if new_value.respond_to?(:blank) && new.blank?

:blank vs. :blank? and new_value vs. new

Looks like the new/new_value error was introduced here: 6d3b49a#diff-4961a18d7c088f36dc4f670c73ae74a6R30

And the other in 2011 or before (so far back, I don’t care anymore). Got test coverage?

Hi, someone changed blacklight_advanced_search to require blacklight 5.10 in between blacklight_advanced_search 5.1.2 and 5.1.3. This means I have no way to fix a bug in 5.1.2 and release it as a backport that still does not require BL 5.10. This is problematic.

In retrospect, I think if you change the gemspec to require more recent versions of BL, it would be good to at least increment the minor version (to 5.2, in this case), to leave room in the version numbers for a backported fix.

I have no idea what, if anything, can/should be done at this point though. I guess I'll just live with the bug I found until I upgrade to BL 5.10, so can upgrade to a blacklight_advanced_search with the fix?

DEPRECATION WARNING: 
Method except! is deprecated and will be removed in Rails 5.1, 
as `ActionController::Parameters` no longer inherits from hash. 
Using this deprecated behavior exposes potential security problems. 
If you continue to use this method you may be creating a security vulnerability 
in your app that can be exploited. Instead, consider using one of these documented 
methods which are not deprecated: 
http://api.rubyonrails.org/v5.0.0.1/classes/ActionController/Parameters.html 
(called from advanced_search_context at .../app/helpers/advanced_helper.rb:37)

Link http://api.rubyonrails.org/v5.0.0.1/classes/ActionController/Parameters.html

Warning appears 14 times during rake ci.

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.

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

2. 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

3. download the latest version of solr (4.7.0)

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

4. minimally configure catalog_controller in “new_search” (the app created in step 1) for this solr index…

catalog_controller and advanced_controller

config.add_facet_field 'cat', :label => 'Category'
config.add_facet_fields_to_solr_request!
config.add_index_field 'cat', :label => 'Category'
config.add_show_field 'cat', :label => 'Category'

config.add_search_field 'all_fields', :label => 'All Fields'
config.add_search_field 'cat', :label => 'Category'

(I got rid of everything else, since this is enough to reproduce the issue)

5. Start up the app

Under my_search

rails server

6. From the home page, click on “more options”

No facets will be displayed on the advanced search page

7. 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

8. 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.

https://blogs.library.ucsf.edu/ckm/2014/03/11/working-with-blacklight-part-3-linking-to-your-solr-index/