blacklight 3.8.2 → 4.0.0.pre6

data/doc/Community-principles.md

@@ -1,44 +0,0 @@
-# Community Principles
-
-## Overview
-* Blacklight is an open source application for libraries (and anyone else), built on top of SOLR, and meant to deliver excellent access to all classes of information resources.
-* Blacklight can ultimately be successful and sustainable in the long run only if it is an open project; that is, it takes contributions from a community of developers across many institutions to enhance and support it
-* We will work to balance progress on Blacklight’s codebase with open community discussion and transparent decision making as coequal goals
-* Blacklight code is available through the Apache 2.0 open source license.
-
-## Technical Leadership
-Technical leadership of the project will be through a small group of proven developers who have demonstrated commitment to Blacklight’s progress and success (and have commit rights to the source code)
-
-Committers must be:
-
-* technically adept
-* constructive, positive members of the Blacklight software community
-* committed to producing useful, practical code for the community
-
-To become a committer, candidates must be…
-
-* nominated by a current committer
-* voted on and approved by a majority of the current committers
-* committers may be voted out at any time by a (super?) majority of the other committers
-
-Committers will have a regular meeting, usually in the form of a conference call, to coordinate development & direction.
-
-Releases will be vetted and controlled by a designated lead or leads. These roles may shift from release to release.
-
-## Code Contributions & Principles
-* the users of, interest in, resources, and talent pool of the Blacklight community will spread far beyond the developers on the committers list, and their institutions
-* Blacklight encourages and will facilitate taking code from contributors from many sources
-the structure of the source code management (soon GIT) will facilitate incorporating and using code from many sources
-* Blacklight committers will actively take code contributions from non-committers and incorporate it into the code trunk
-* Working code wins
-* You get what you give
-* All contributed code must have full test coverage before it is committed. The current testing infrastructure is RSpec for everything but Rails views, and Cucumber for for Rails views.
-* Tests must be committed at the same time code is.
-* All javascript features (where feasible) should be added using “progressive enhancement” or “unobtrusive javascript” styles. Meaning the basic feature should work without Javascript, and the JS should be added as a progressive enhancement, and added via externally linked js files, not in-line in html source as script tags, onclick attributes, etc.
-* All bugs and development tasks will be tracked in GitHub Issues
-* All code must be documented before it’s committed
-
-## Roadmap & Transparency
-We will publish a roadmap to guide overall development. The items on this roadmap will be determined after an inclusive process of canvassing the wider Blacklight community, including code committers, contributors, users and a potential advisory board.
-
-We envision regular/quarterly/semiannual/annual Blacklight convention of community members to help guide and galvanize new developments. These are likely to be appended to other community events, e.g., code4lib, for the sake of logistics.

data/doc/Configuring-and-Customizing-Blacklight.md

@@ -1,271 +0,0 @@
-# Configuring and Customizing Blacklight
-
-There are lots of ways to override specific behaviors and views in Blacklight. Blacklight is distributed as a Ruby gem with a Rails Engine framework built in. All customization of Blacklight behavior should be done within your application (partly as good practice, but also to not lose your changes with every new Blacklight release).
-
-If you find that there is no other way to make your customization, please describe your problem on the [[mailing list|http://groups.google.com/group/blacklight-development]] -- we'll do the best we can to help out, and even make changes to Blacklight as needed. If you are interested in contributing code to Blacklight, see the [[Contributing to Blacklight]] page.
-
-## Configuration
-
-
-Blacklight provides a Ruby on Rails -based interface to the Apache Solr Enterprise Search Server. More information about Solr is available at the [[Solr web site|http://lucene.apache.org/solr/]]. In order to fully understand this section, you should be familiar with Solr, ways to index data into Solr, how to configure request handlers, and how to change a Solr schema.  Those topics are covered in the official [Apache Solr Tutorial](http://lucene.apache.org/solr/tutorial.html).
-
-Although the out-of-the-box Blacklight application is configured to work with library MARC-based data, the configuration is easy to extend and modify to meet other needs.  **All of these configurations for facet fields, index fields, solr search params logic, etc. go in your CatalogController**.  By default, this will be located at *app/controllers/catalog_controller.rb*  
-
-**Note:** While it is sufficient to have just one CatalogController, You can actually create multiple variations of the catalog controller (ie. MusicCatalog, DvdCatalog), each with its own configuration settings and URL routing.
-
-Once you have your Solr fields, you can then configure your Blacklight application to display arbitrary fields in different contexts
-
-### Choose which Fields to Display in Search Results
-
-* Displayed fields and labels can be customized on both the search results and document views.
-Note that these must be STORED fields in the Solr index.
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # solr fields to be displayed in the index (search results) view
-    #   The ordering of the field names is the order of the display 
-    config.add_index_field 'title_display', :label => 'Title:' 
-    config.add_index_field 'title_vern_display', :label => 'Title:' 
-    config.add_index_field 'author_display', :label => 'Author:' 
-    config.add_index_field 'author_vern_display', :label => 'Author:'    
-```
-
-### Targeting Search Queries at Configurable Fields
-
-* Search queries can be targeted at configurable fields (or sets of fields) to return precise search results. Advanced search capabilities are provided through the [[Advanced Search Add-On|https://github.com/projectblacklight/blacklight_advanced_search]] 
-[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_fields.png|frame|alt=Search fields in action]]
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # Now we see how to over-ride Solr request handler defaults, in this
-    # case for a BL "search field", which is really a dismax aggregate
-    # of Solr search fields. 
-    
-    config.add_search_field('title') do |field|
-      # solr_parameters hash are sent to Solr as ordinary url query params. 
-      field.solr_parameters = { :'spellcheck.dictionary' => 'title' }
-
-      # :solr_local_parameters will be sent using Solr LocalParams
-      # syntax, as eg {! qf=$title_qf }. This is neccesary to use
-      # Solr parameter de-referencing like $title_qf.
-      # See: http://wiki.apache.org/solr/LocalParams
-      field.solr_local_parameters = { 
-        :qf => '$title_qf',
-        :pf => '$title_pf'
-      }
-    end
-```
-
-### Choosing & Configuring Facets
-
-- Faceted search allows users to constrain searches by controlled vocabulary items
-[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_facets.png|frame|alt=Search facets in action]]
-Note that these must be INDEXED fields in the Solr index, and are generally a single token (e.g. a string).
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # solr fields that will be treated as facets by the blacklight application
-    #   The ordering of the field names is the order of the display
-    config.add_facet_field 'format', :label => 'Format' 
-    config.add_facet_field 'pub_date', :label => 'Publication Year' 
-    config.add_facet_field 'subject_topic_facet', :label => 'Topic', :limit => 20 
-    config.add_facet_field 'language_facet', :label => 'Language', :limit => true 
-```
-
-Blacklight also supports Solr facet queries:
-
-```ruby
-    config.add_facet_field 'pub_date_query', :label => 'Publication Year', :query => {
-      :last_5_years => { :label => 'Last 5 Years', :fq => "[#{Time.now.year-5} TO *]"}
-    } 
-```
-
-You can also tell Solr how to sort facets (either by count or index):
-Note: setting 'index' causes Blacklight to sort by count and then by index. If your data is strings, you can use this to perform an alphabetical sort of the facets.
-```ruby
-   config.add_facet_field :my_count_sorted_field, :sort => 'count'
-   config.add_facet_field :my_index_sorted_field, :sort => 'index'
-```
-
-
-If you want Solr to add the configured facets and facet queries to the Solr query it sends, you should also add:
-
-```ruby
-    config.add_facet_fields_to_solr_request!
-```
-
-If you have date facets in Solr, you should add a hint to the Blacklight configuration:
-
-```ruby
-   config.add_facet_field :my_date_field, :date => true
-```
-
-This will trigger special date querying logic, and also use a localized date format when displaying the facet value. If you want to use a particular localization format, you can provide that as well:
-
-```ruby
-   config.add_facet_field :my_date_field, :date => { :format => :short }
-```
-
-### Map from User Queries to Solr Parameters
-
-* Blacklight provides flexible mapping from user queries to solr parameters, which are easily overridden in local applications (see [[Extending or Modifying Blacklight Search Behavior]]).
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # Each symbol identifies a _method_ that must be in
-    # this class, taking two parameters (solr_parameters, user_parameters)
-    # Can be changed in local apps or by plugins, eg:
-    # CatalogController.include ModuleDefiningNewMethod
-    # CatalogController.solr_search_params_logic << :new_method
-    # CatalogController.solr_search_params_logic.delete(:we_dont_want)
-    self.solr_search_params_logic = [:default_solr_parameters , :add_query_to_solr, :add_facet_fq_to_solr, :add_facetting_to_solr, :add_sorting_paging_to_solr ]
-```
-
-> Source: [[./lib/blacklight/solr_helper.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L70]]
-
-### Document Extension Framework
-
-The main use case for extensions is for transforming a Document to another
-format. Either to another type of Ruby object, or to an exportable string in
-a certain format. 
-
-An Blacklight::Solr::Document extension is simply a ruby module which is mixed
-in to individual Document instances.  The intended use case is for documents
-containing some particular format of source material, such as Marc. An
-extension can be registered with your document class, along with a block
-containing custom logic for which documents to apply the extension to.
-
-```ruby
-    SolrDocument.use_extension(MyExtension) {|document| my_logic_on_document(document}
-```
-
-MyExtension will be mixed-in (using ruby 'extend') only to those documents
-where the block results in true.
-
-Underlying metadata formats, or other alternative document views, are linked to from the HTML page <head>. 
-
-# Customizing the User Interface
-## Layouts 
-
-The built-in Blacklight controllers all by default use a Rails view layout called "blacklight", that lives in the Blacklight source. This ends up being a bit confusing, but is the best way we have at present to have out of the box default using a layout with full functionality, without stepping on a possibly existing local 'application' layout. 
-
-To change what layout the Blacklight controllers use, simply implement a method #layout_name in your local application_controller.rb that returns the name of the layout you'd like them to use. 
-
-```ruby
-# [from app/controllers/application_controller.rb]
-class ApplicationController < ActionController::Base
-  ...
-    def layout_name
-       "application"
-    end
-  ...
-end
-```
-
-When implementing your own layout instead of using the stock one, you may want to look at the Blacklight app/views/layouts/blacklight.html.erb file to see what helper methods are called there, to maintain full Blacklight functionality you may want to call these same helper methods. 
-
-* `render_head_content` renders content within the
-  html `<head>` tag, which includes document-specific alternative
-formats as well as tags generated by plugins, etc.
-* `sidebar_items` renders features including sidebar content, e.g. facet
-  lists.
-* flash messages
-* user util links
-
-## Overriding Views (templates and partials)
-As a Rails Engine, you can easily override views in your app. You can see what views and partials are provided by looking in `[[./app/views|https://github.com/projectblacklight/blacklight/tree/master/app/views]]` inside the Blacklight source.
-
-Once you find the view you'd like to change, you should create a file with the same name and relative path in your own application (e.g. if you wanted to override [[./app/views/catalog/_show_partials/_default.html.erb|https://github.com/projectblacklight/blacklight/blob/master/app/views/catalog/_show_partials/_default.html.erb]] you would create ./app/views/catalog/_show_partials/_default.html.erb in your local application. Frequently, you will start by copying the existing Blacklight view and modifying it from there.
-
-It is generally recommended that you override as little as possible, in order to maximize your forward compatibility. Look to override either a small, focused partial template, or a helper method of partial template called from a larger template, so your application's version can call out to those same helpers or partial templates within blacklight core code. 
-
-## Overriding the CatalogController
-Overriding the Blacklight `CatalogController` implementation is easy, and the skeleton of the `CatalogController` is generated into your application for you when you install Blacklight. 
-
-See the [[Extending or Modifying Blacklight Search Behavior]] for tips and approaches to customizing the catalog.
-
-## Overriding Other Controllers
-
-1. Find the controller you're interested in blacklight's app/controllers/  . 
-2. Create a file with the same name in your local app/controllers. 
-3. This file requires the original class, and then re-opens it to add more methods.
- 
-```ruby
-require "#{Blacklight.controllers_dir}/some_controller"
-
-class SomeController < ApplicationController
-   # custom code goes here
-end
-```
-
-In that "custom code goes here", you can redefine certain methods (action methods or otherwise) to do something different.  You can also add new methods (again action methods or otherwise), etc. 
-
-It's kind of hard to call 'super' to call original functionality: 
-
-* the ruby language features here make 'super' unavailable, although you can work around that confusingly with the rails #alias_method_chain method. 
-* but more importantly, action methods in particular don't really suit themselves to being over-ridden and called by super, because the original implementation often does something you'd want to change but there's no easy way to 'undo' -- calling 'render', which can only be called once. 
-
-So basically, if you find yourself wanting to access some functionaltiy in the original implementation of a method that you also want to over-ride -- the best solution is probably to refactor Blacklight core code to put that functionality in a subsidiary method, so you can over-ride the action method entirely but call that logic from core.  Action methods should be short and sweet anyway. 
-
-
-## Custom View Helpers
-
-(This is accurate for Blacklight 3.1.1 and subsequent. Before that, things were messier). 
-
-One of the most common things you might need to do is create a view helper -- especially to override some Blacklight behavior implemented in it's own view helpers. The first step is looking at Blacklight source to determine what view helper method you want to override. 
-
-Blacklight comes packaged with several view helper modules. There is a BlacklightHelper in (blacklight source) app/helpers/blacklight_helper.rb , and several others that correspond to specific controller. (Note, depending on version of Rails and configuration, all helpers may get loaded for every request, even ones that are named to correspond only to a particular other controller). 
-
-If you simply created a local helper with the same name as a helper in Blacklight, that will end up preventing the Blacklight helper from being loaded at all though, which is not what you want to do to override. 
-
-We've structured each Blacklight view helper module into two parts to make it easy to selectively over-ride methods. For instance, here's Blacklight's app/helpers/blacklight_helper.rb:
-
-```ruby
-module BlacklightHelper
-  include Blacklight::BlacklightHelperBehavior
-end
-```
-
-Now, the actual methods will be found in app/helpers/blacklight/blacklight_helper_behavior.rb instead. 
-
-If you want to over-ride a helper method, copy the wrapper blacklight_helper into your local app, with the 'include' line, and now you can individually over-ride methods from BlacklightHelperBehavior, and the other methods you don't over-ride will still have their default implementation. 
-
-YOUR `app/helpers/blacklight_helper.rb`
-
-```ruby
-module BlacklightHelper
-  include Blacklight::BlacklightHelperBehavior
-
-  def application_name
-    "Bestest University Search"
-  end
-end
-```
-
-One helper you might want to over-ride for customization is #render_document_partial (currently defined in [[blacklight_helper|https://github.com/projectblacklight/blacklight/blob/master/app/helpers/blacklight_helper.rb]]), which you can over-ride to choose differnet local partial views to display a document on search results or detail page, possibly varying depending on type of document according to your own local logic. 
-
-## Adding in your own CSS or Javascript
-
-Within your local application, you can use the [[Rails Asset Pipeline|http://guides.rubyonrails.org/asset_pipeline.html]] to manipulate javascript and css documents.
-
-**todo??** better instructions for over-riding BL's built in CSS using SASS? (jrochkind thought jamesws wrote such already, but can't find them now)
-
-The Blacklight generator added a file to your app at `./app/assets/stylesheets/blacklight_themes/standard.css.scss`, elements of the BL default theme can be customized or over-ridden there. If there's something you want to do but aren't sur e the best way, feel free to ask on the listserv. 
-
-### jquery-ui
-
-Blacklight by default uses [jquery-ui](http://jqueryui.com/) for some UI widgets.  
-
-The Blacklight gem provides it's own JQuery-UI theme, and makes it work with the rails asset pipeline even precompiled. (as of BL 3.3.1).  
-
-To disable Blacklight's provision of JQuery-UI theme:
-
-* comment out `*= require 'jquery/ui-lightness/jquery-ui-1.8.1.custom.css'` from your `./app/assets/stylesheets/application.css`
-* add `Blacklight::Engine.config.jquery_images=false` to your `./config/application.rb` or some other control point that happens before Rails initialization. 
-
-Then [create your own JQuery-UI theme](http://jqueryui.com/themeroller/), and set it up yourself to be included and used in the rails asset pipeline. This can be tricky, [here's a blog post on options](http://bibwild.wordpress.com/2011/12/08/jquery-ui-css-and-images-and-rails-asset-pipeline/). 
-
-## See also
-
-* [[Extending or Modifying Blacklight Search Behavior]]
-* [[Pagination]]

data/doc/Contributing-to-Blacklight.md

@@ -1,25 +0,0 @@
-# Contributing to Blacklight
-Blacklight is a collaborative open source project by developers at various institutions, which we each work on largely motivated by our own local institutions' needs. We work on the shared project together so we can benefit from each other's code, but most developers primary priorities are to their own local development. In this it is like many such projects.
-
-The Blacklight developers do want to create a product that is easy for newcomers to install and get started with -- both as a service to the community and in the interests of our own institutions in creating a sustainable project and product that continue to thrive through personnel changes. However, the developers may not always have time to find or fix bugs that may be affecting you, or lead you through every detail of getting Blacklight to work for you.
-
-But we do try when we can -- please don't be scared to ask a question on the [[Blacklight mailing list|http://groups.google.com/group/blacklight-development]], just don't be shocked if we can't always give you the answer you want. We always welcome patch submissions; and we are always excited to hear about what others are doing with Blacklight. We're also always looking for more committers, although we usually like to see a patch or two before considering granting committer status.
-
-If you follow this short guide, it will make it much easier for the community to review your changes, and the core team to get them included in the next release. If you are new to Git, be sure to read Github's (really good) [[step-by-step directions|http://help.github.com/fork-a-repo/]] for contributing to projects. If you want a basic introduction to git, check out [[Git Reference|http://gitref.org/]].
-
-We also encourage a lot of peripheral functionality -- especially for features that may not be used by most implementations, as the Blacklight install base has a wide range of users -- to consider developing stand-alone, optional [[Blacklight add-ons]].
-
-## Adding a ticket
-Let us know you're interested in working on a feature by filing a ticket in our [[issue tracker|https://github.com/projectblacklight/blacklight/issues]].  
-
-## Making Your Changes
-
-* Fork the project (Github has really good step-by-step directions
-* Start a feature/bugfix branch
-* Commit and push until you are happy with your contribution
-* Make sure to add tests for it. This is important so we don't break it in a future version unintentionally.
-* After making your changes, be sure to run the [[Blacklight rspec and cucumber tests|Testing]] to make sure everything works. 
-* Submit your change as a [[Pull Request|http://help.github.com/pull-requests/]].
-
-## Support
-If you are interested in working on the Blacklight plugin, but want guidance or support, please send an email to our [[Blacklight-development mailing list|http://groups.google.com/group/blacklight-development]] and we'll be glad to help.

data/doc/Examples.md

@@ -1,62 +0,0 @@
-You can see a demonstration of the generic Blacklight plugin at http://demo.projectblacklight.org
-
-Columbia University:
-
-* Academic Commons (Institutional Repository) - http://academiccommons.columbia.edu/
-* New Arrivals (Subset of OPAC) - http://newarrivals.cul.columbia.edu
-* Staff Collection Viewer (Internal only)
-* CLIO Beta (opac replacement + metasearch) - http://cliobeta.columbia.edu
-
-Agriculture Network Information Center
-http://www.agnic.org/search
-
-Historical State (NCSU Libraries)
-http://historicalstate.lib.ncsu.edu
-
-Johns Hopkins University Libraries (Catalyst)
-http://catalyst.library.jhu.edu
-
-Northwest Digital Archives
-http://nwda.projectblacklight.org
-
-Northwestern University Library Archival and Manuscript Collections
-http://findingaids.library.northwestern.edu
-
-NRM (Natural Resource Management) knowledge online
-http://nrmonline.nrm.gov.au/
-
-Rock & Roll Hall of Fame
-http://catalog.rockhall.com/
-
-Stanford University
-http://searchworks.stanford.edu
-
-University of Virginia
-http://search.lib.virginia.edu
-
-University of Wisconsin-Madison
-http://forward.library.wisconsin.edu/
-
-United States Holocaust Memorial Museum
-(Currently internal only; public instance soon)
-
-WGBH Open Vault
-http://openvault.wgbh.org
-
-NCSU Libraries' Digital Collections: Rare and Unique Materials
-http://d.lib.ncsu.edu/collections/
-
-University of Hull:
-
-* Institutional repository - http://hydra.hull.ac.uk
-* Library catalogue prototype - http://blacklight.hull.ac.uk/
-
-The UI component of the Hydra Framework - http://projecthydra.org
-
-The New York Public Library
-
-* Andre Studios 1930-1941 - http://andrestudios.nypl.org 
-
-## Media/Presentations
-
-* ["Highly Relevant Search Result Ranking for Large Law Enforcement Information Sharing Systems"](http://www.lucidimagination.com/blog/2011/06/01/solr-and-law-enforcement-highly-relevant-results-can-be-a-crime/), presented by Ronald Mayer of Forensic Logic at Lucene Revolution 2011 - Blacklight was used to quickly provide a proof-of-concept on law enforcement data.

data/doc/Extending-or-Modifying-Blacklight-Search-Behavior.md

@@ -1,141 +0,0 @@
-# Extending or Modifying Blacklight Search Behavior
-
-Solr parameters used by for a given request can come from several different places. 
-
-* Solr request handler: `solrconfig.xml` in your solr config
-* Application logic: logic in the BL rails app itself
-
-## Solr request handler
-
-The Solr [[Request Handlers|http://wiki.apache.org/solr/SolrRequestHandler]] may be configured in the [[solrconfig.xml|http://wiki.apache.org/solr/SolrConfigXml]] and are baked into the request handler itself. Depending on how you have blacklight configured, your app may be using the same Solr request handler for all searches, or may be using different request handlers for different "search fields".  
-
-The request handler is often set up with default parameters:
-
-```xml
-  <requestHandler name="standard" class="solr.SearchHandler" >
-     <lst name="defaults">
-       <str name="echoParams">explicit</str>
-       <str name="rows">10</str> 
-       <str name="fl">*</str>   
-       <str name="facet">true</str>
-       <str name="facet.mincount">1</str>
-       <str name="facet.limit">30</str> 
-       <str name="facet.field">access_facet</str>
-       <str name="facet.field">author_person_facet</str>
-       <str name="facet.field">author_other_facet</str>
-       <str name="facet.field">building_facet</str>
-       <str name="facet.field">callnum_1_facet</str>
-       <str name="facet.field">era_facet</str>
-       <str name="facet.field">format</str>
-       <str name="facet.field">geographic_facet</str>
-       <str name="facet.field">language</str>
-       <str name="facet.field">pub_date_group_facet</str>
-       <str name="facet.field">topic_facet</str>
-     </lst>
-  </requestHandler>
-```
-## Configuration
-
-The default application logic (explained below) looks in configuration for things like the name of a the solr request handler to use, and default request parameters to send on every solr search request (or with every request from a certain blacklight search type/field). An example getting started configuration is generally installed into your app when you install Blacklight at `[[./app/controllers/catalog_controller.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/generators/blacklight/templates/catalog_controller.rb]]`.
-
-## Application logic
-
-The logic Blacklight uses to determine how to map user-supplied parameters into Solr request parameters for a given application request is in the [[#solr_search_params method in the SolrHelper module|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L76]]. Note that `[[CatalogController|https://github.com/projectblacklight/blacklight/blob/master/app/controllers/catalog_controller.rb]]` extends `[[SolrHelper|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb]]`, so the `SolrHelper` methods become available in the `CatalogController` (and other controllers, if they extend `SolrHelper` too). 
-
-Behind the scenes, #solr_search_params uses the `class_inheritable_accessor` method [[solr_search_params_logic|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L30]]. solr_search_params_logic is essentially a class variable that is mixed into the CatalogController and provides an ordered list of methods to call that may inspect the supplied user parameters and add, remove, or modify the Solr request parameters that will be sent to an [[RSolr|https://github.com/mwmitchell/rsolr/]] object, which in turn will convert the hash into query parameters for a Solr request. One confusing thing is that RSolr and  [[RSolr-ext|https://github.com/mwmitchell/rsolr-ext]] provide their own mappings from certain custom terms to Solr-recognized request parameters. For instance, a `:per_page` key in that hash will get mapped to the Solr `&rows` parameter -- but a `:rows` key will also.  Blacklight developers have found that using these special RSolr "aliases" leads to confusion, as well as confusing bugs (if both `:per_page` and `:rows` are set in the hash, what happens can be hard to predict).  So we try to avoid using the special RSolr aliases, and just use ordinary Solr parameters in our hashes. But you may encounter older code that uses the RSolr aliases. 
-
-There can be similar confusing behavior or bugs if one piece of code adds a key to a `Hash` using a `Symbol`, but another piece of code looks for and/or adds that same key to the `Hash` using a `String` instead. RSolr happens to accepts either one, but if both are present RSolr behavior can be unexpected. And even before it gets to RSolr, you may have code that thinks it replaced a key but did not becuase it was using the wrong form. Blacklight developers have agreed to try and always use `Symbol` based keys in hashes meant for Solr parameters, to try and avoid these problems. Longer term, we could probably make some code changes to make this kind of error less likely. 
-
-The default `#solr_search_params_logic` is meant to handle very common cases and patterns based on simple configuration options from the controller and the user-supplied URL parameters.
-
-* `[[blacklight_config.default_solr_params|https://github.com/projectblacklight/blacklight/blob/master/lib/generators/blacklight/templates/catalog_controller.rb#L9]]`
-    * Default params sent to solr with every search, including the default :qt param, which determines which Solr request handler will be targetted. Some people like to use solrconfig.xml request handler defaults exclusively, and include only a :qt here; others find it more convenient to specify some defaults at the application level here. 
-* `[[blacklight_config.search_fields|https://github.com/projectblacklight/blacklight/blob/master/lib/generators/blacklight/templates/catalog_controller.rb#L81]]`
-   * Each search field will be presented in a select menu in the BL user interface search box. These 'search fields' don't neccesarily correspond 1-to-1 with Solr fields. What they instead correspond to is Solr parameter over-rides that will be used for this BL UI search field.  Those over-rides are present here. 
-   * You could simply chose a different `:qt` Solr request handler for each search field, which has it's own default parameters in the sorlconfig.xml. This is what we started out doing with Solr, but found it led to much duplication of information in solrconfig.xml. 
-   * You can continue using the same Solr request handler, but simply specify different parameters which will be included in the http query string sent to Solr here, with the `:solr_parameters`  key. This works fine, but some people don't like how it makes your Solr requests much longer/more complex in the Solr logs; and/or they prefer to control this Solr side instead of Application side. 
-   * For the best of both worlds, although it's a bit confusing at first, you can use the `:solr_local_parameters` key to have parameters supplied to Solr using the Solr [[LocalParams|http://wiki.apache.org/solr/LocalParams]] syntax, which means you can use "parameter dereferencing"  with dollar-sign-prefixed references to variables defined in solrconfig.xml request handler. This is what the current example BL setup does. 
-
-So the default implementation of `#solr_search_params` takes these configured parameters, combines them with certain query parameters from the current users HTTP request to the BL app, and prepares a Hash of parameters that will be sent to solr. For common use patterns, this is all you need. 
-
-But sometimes you want to add some custom logic to `#solr_search_params` to come up with the solr params Hash in different ways. Typically to support a new UI feature of some kind, either in your local app or in a Blacklight add-on plugin you are developing. 
-
-
-# Extending Blacklight::SolrHelper#solr_search_params
-
-To add new search behaviors (e.g. authorization controls, pre-parsing query strings, etc), the easiest route is to add additional steps to the `#solr_search_params_logic`, either at the beginning of the list (to set default parameters) or at the end of the list (to force particular parameters). Because `#solr_search_params_logic` is just an ordinary array, you may perform any normal array operation (e.g. push/pop/delete/insert) to customize the parameter generation to meet your needs.
-
-`#solr_search_params_logic` steps take two inputs, the hash of `solr_parameters` and the hash of `user_parameters` (often provided by the URL parameters), and modifies the `solr_parameters` directly, as needed. 
-
-You can add custom solr_search_params_logic steps within your controller (or in many other places, including initializers, mixins, etc) by adding a Symbol with the name of a method (provided by the controller) you wish to use, e.g.:
-
-*./config/initializers/blacklight_config.rb*
-
-```ruby
-class CatalogController
-  self.solr_search_params_logic += :show_only_public_records
-end
-```
-The controller must provide the method added to `solr_search_params_logic`, in this case `show_only_public_records`. It is often convenient to do this in a separate `Module` and include it into the controller:
-
-*./app/controllers/catalog_controller.rb*
-
-```ruby
-require 'blacklight/catalog'
-class CatalogController < ApplicationController 
-  include Blacklight::Catalog
-  include MyApplication::SolrHelper::Authorization
-  
-  # Instead of defining this within an initializer, you may instead wish to do it on the controller directly:
-  # self.solr_search_params_logic << :show_only_public_records
-
-  # You could also define the actual method here, but this is not recommended.
-  # def show_only_public_records solr_parameters, user_parameters
-  #  [...]
-  # end
-end
-```
-
-The included module then defines the logic method:
- 
-*./lib/my_application/solr_helper/authorization.rb*
-
-```ruby
-module MyApplication::SolrHelper::Authorization
-#  You could also add the logic here
-#  def self.included base
-#    base.solr_search_params_logic << :show_only_public_records
-#  end
-
-  # solr_search_params_logic methods take two arguments
-  # @param [Hash] solr_parameters a hash of parameters to be sent to Solr (via RSolr)
-  # @param [Hash] user_parameters a hash of user-supplied parameters (often via `params`)
-  def show_only_public_records solr_parameters, user_parameters
-    # add a new solr facet query ('fq') parameter that limits results to those with a 'public_b' field of 1 
-    solr_parameters[:fq] ||= []
-    solr_parameters[:fq] << 'public_b:1'
-  end
-end
-```
-
-## Other examples
-
-In addition to providing this behavior locally, some Blacklight plugins also extend the `#solr_search_params`:
-
-* [[Blacklight Range Limit|https://github.com/projectblacklight/blacklight_range_limit/blob/master/lib/blacklight_range_limit/controller_override.rb]]
-
-* A walk through on adding a checkbox limit at: http://bibwild.wordpress.com/2011/06/13/customing-blacklight-a-limit-checkbox/
-
-* A much more complicated walk-through on adding an 'unstemmed search' checkbox limit: http://bibwild.wordpress.com/2011/06/20/customizing-blacklight-disable-automatic-stemming/
-
-## Suppressing search results
-
-You can configure your `solrconfig.xml` to not show results based on fields in your solr document.  For example, if you have a solr boolean field such as `show_b`, you can suppress any records that have this field present.  To do so, add:
-```
-<lst name="appends"><str name="fq">-show_b:["" TO *]</str></lst>
-```
-to the request handler in your `solrconfig.xml` file.  If you would like this to be for standard solr searches, add the above line to this request handler:
-```
-<requestHandler name="search" class="solr.SearchHandler" default="true">
-```
-By doing so, solr queries that use the "document" request handler will still give you any records with the show_b field, but solr queries with the "search" handler will not.