blacklight 5.9.4 → 5.10.0

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.

data/doc/Home.md

@@ -1,100 +0,0 @@
-> NOTE: This wiki provides developer documentation for the latest Blacklight release. For documentation of older releases, see the end of this page.
-
-Blacklight is an open source, Ruby on Rails Engine that provides a basic discovery interface for searching an [Apache Solr](http://lucene.apache.org/solr) index, and provides search box, facet constraints, stable document urls, etc., all of which is customizable via Rails (templating) mechanisms. Blacklight accommodates heterogeneous data, allowing different information displays for different types of objects. 
-
-Some other features include:
-
-* Stable URLs for search and record pages allow users to bookmark, share, and save search queries for later access
-* Every Blacklight search provides RSS and Atom Responses of search results
-* For certain types of solr documents, an OpenURL/Z39.88 COinS object is embedded in each document, which allows plugins like Zotero to easily extract data from the page.
-* Blacklight supports OpenSearch, a collection of simple formats for the sharing of search results.
-* Faceted searching
-* Search queries can be targeted at specific sets of fields
-* Results sorting
-* Tools for exporting records to Refworks or Endnote, sending records via Email or SMS, or as a formatted citation.
-
-## About this guide
-
-This wiki provides high-level documentation of Blacklight and supplements the low-level [RubyDocs](http://rubydoc.info/gems/blacklight). It is structured to address a broad spectrum of needs, ranging from new developers getting started to well-experienced developers extending their application or troubleshooting. It should be of use at any point in the application life cycle.
-
-This wiki assumes you have prior experience with Ruby and Ruby on Rails. If you have no prior experience with either, you will find a very steep learning curve diving straight into Blacklight. There are some good free resources on the internet for learning Ruby, including:
-
-- [Mr. Neighborly's Humble Little Ruby Book](http://www.humblelittlerubybook.com/)
-- [Programming Ruby](http://ruby-doc.com/docs/ProgrammingRuby/)
-- [Why's (Poignant) Guide to Ruby](http://mislav.uniqpath.com/poignant-guide/)
-
-And resources for learning Rails, including:
-
-- [Rails tutorial](http://ruby.railstutorial.org/)
-- [Learn Rails](https://learn.thoughtbot.com/rails)
-- [Railsbridge](http://docs.railsbridge.org/docs/)
-
-In order to fully understand this guide, you should also familiarize yourself with Apache Solr, ways to index data into Solr, how to configure request handlers, and the Solr schema format. Those topics are covered in the official [Apache Solr Tutorial](http://lucene.apache.org/solr/tutorial.html).
-
-## Blacklight features
-* [[Basic features|Blacklight out-of-the-box]]
-* [[Internationalization]]: Translating (or simply customizing) the Blacklight copy
-* APIs: [[Atom Responses]], [[JSON API]]
-* [[Directory of Blacklight Plugins/Addons|Blacklight-Add-ons]]
-
-## Blacklight Configuration
-
-Blacklight tries to address the "80% use case" out of the box and through some simple configuration can be adapted to work with your data. The available Blacklight configuration, and their default values, is shown in
-[`blacklight/configuration.rb`](https://github.com/projectblacklight/blacklight/tree/master/lib/blacklight/configuration.rb).
-
-The Blacklight configuration is an `OpenStruct`; in addition to the Blacklight-defined configuration discussed in the sections below, you may also add application-specific configuration (e.g. for controlling behavior in overridden partials) or plugin-specific configuration.
-
-* [[Solr Configuration]]
-* [[Discovery|Configuration - Solr fields]]
-* [[Results view|Configuration - Results View]]
-* [[Facets|Configuration - Facet Fields]]
-
-## Blacklight Customization
-
-There are many ways to override specific behaviors and views in Blacklight. Because Blacklight is distributed as a Rails engine-based gem, all customization of Blacklight behavior should be done within your application by overriding Blacklight-provided behaviors with your own.
-
-* [[Understanding Rails and Blacklight]] How the Blacklight engine integrates with your application
-* [[Extending or Modifying Blacklight Search Behavior]] How to change the way the Blacklight discovery feature works.
-* [[Adding new document actions]] How to extend the document actions with application-specific behavior
-
-### Customizing the UI
-
-* [[Theming]]: Overriding the Blacklight CSS
-* [[Providing your own view templates]]: Overriding the out-of-the-box Blacklight templates the Rails way.
-* [[Pagination]]: Advice on how to customize pagination with Kaminari
-
-### Other Customizations
-* [[User Authentication]]: Connecting Blacklight with an existing Authentication system
-* [[Configuring Rails Routes]]
-* [[Indexing your data into Solr]]
-* [[Additional Blacklight-specific Solr documentation|README_SOLR]]
-
-## Support
-Don't be scared to ask a question on the [[Blacklight mailing list|http://groups.google.com/group/blacklight-development]]. We appreciate you checking the documentation first and asking an educated question, but don't beat your head against the wall -- sometimes the existing documentation may be out of date and inaccurate.
-
-In order to reduce spam, the first time you post your email will be held in a moderation queue, but as soon as your first message is approved your posts won’t be held for moderation any longer. 
-
-Some Blacklight developers aso hang out on our IRC channel, usually during North American office hours. On `chat.freenode.net`, channel `#blacklight`. Stop in and say hi, we're happy to help with questions when we have time. [[http://freenode.net/faq.shtml]].
-
-* [[Bug Tracker|https://github.com/projectblacklight/blacklight/issues/]]
-* [[Mailing List|http://groups.google.com/group/blacklight-development]]
-* [![Build Status](https://travis-ci.org/projectblacklight/blacklight.png?branch=master)](https://travis-ci.org/projectblacklight/blacklight)
-
-## Contributing to Blacklight
-
-* [[Contributing to Blacklight]]
-* [[How to release a version]]
-* [[Testing]]
-
-### Older Documentation
-This wiki provides developer documentation for the ```master``` branch of Blacklight, which may include documentation of features not present in every Blacklight version. For documentation of specific Blacklight releases, see also:
-
-* [[Home]]
-* [[Blacklight 4.7|https://github.com/projectblacklight/blacklight/tree/release-4.7/doc]]
-* [[Blacklight 3.x|https://github.com/projectblacklight/blacklight/tree/release-3.8/doc]]
-* [[Blacklight 3.0 or 3.1|https://github.com/projectblacklight/blacklight/tree/release-3.1/doc]]
-* [[Blacklight 2.x|https://github.com/projectblacklight/blacklight/tree/v2.9-frozen/doc]] for all Blacklight 2.x releases; version-specific documentation is also available:
-    * [[Blacklight 2.7|https://github.com/projectblacklight/blacklight/tree/v2.7.0/doc]]
-    * [[Blacklight 2.6|https://github.com/projectblacklight/blacklight/tree/v2.6.0/doc]]
-    * [[Blacklight 2.5|https://github.com/projectblacklight/blacklight/tree/v2.5.0/doc]]
-    * [[Blacklight 2.4|https://github.com/projectblacklight/blacklight/tree/v2.4.2/doc]]

data/doc/How-to-release-a-version.md

@@ -1,45 +0,0 @@
-Before releasing, ensure that you're on the master branch.  Run all  tests and ensure that they pass. Also check the [[continuous integration server|https://travis-ci.org/projectblacklight/blacklight]] to make sure tests are passing.
-    ```bash
-    $ bundle exec rake
-    ```
-
-1. Update the version number in ./VERSION
-    ```
-    {major}.{minor}.{patch}
-    ```
-
-1. Fix GitHub issue tracker to know about the release
-      * Create a milestone in GitHub for the NEXT version.
-      * Move any open tickets for released version to the next version.
-      * Mark the milestone as closed.
-
-1. Write Github [release notes](https://github.com/projectblacklight/blacklight/tags) for the tag, using this template:
-
-```code
-[Commit History](https://github.com/projectblacklight/blacklight/compare/v5.x.0...v5.x.0) | [Milestone](https://github.com/projectblacklight/blacklight/issues?q=milestone:{milestone here})
-
-(anything important about this release, themes, etc)
-
-### New Features and improvements
-
-(#ticketnumber and a human-readable description of the ticket, usually the ticket title. If the ticket title doesn't make sense, either edit the ticket directly, or provide an alternative title here)
-
-##  Bug Fixes
-
-### Upgrade Notes
-
-(anything special that needs to be called out)
-```
-
-1. Prepare announcement
-  * Include URL to GitHub closed issues for version 
-  * Include URL to github commits between tags. github can show all commits between two versions with a URL of this form: [[http://github.com/projectblacklight/blacklight/compare/v2.5.0...v2.6.0]]  Replace with previous version and current release version tags. 
-  * Include URL to the Github release notes
-
-1. Release the gem 
-```bash
-$ rake release
-```
-
-1. Announce
-  * Write emails announcing the release to Blacklight Development 

data/doc/Indexing-your-data-into-solr.md

@@ -1,36 +0,0 @@
-Blacklight uses Solr as its data index. Blacklight is agnostic as to how that Solr index gets populated. Initial Blacklight development was geared towards work in university libraries, and deals with library data in the MARC format. The Blacklight out-of-the-box demo and test suite is geared towards that use case, but Blacklight itself is not limited to only serving MARC-based data.
-
-## Common Patterns
-
-* [[Sunspot for Indexing]]
-
-* If you're not dealing with MARC records, you might do something like the following:
-
-```
-    class MyModel < ActiveRecord::Base
-      after_save :index_record
-      before_destroy :remove_from_index
-
-      attr_accessible :field_i_want_to_index
-
-      def to_solr
-        # *_texts here is a dynamic field type specified in solrconfig.xml
-        {'id' => id,
-         'field_i_want_to_index_texts' => field_i_want_to_index}
-      end
-
-      def index_record
-        SolrService.add(self.to_solr)
-        SolrService.commit
-      end
-
-      def remove_from_index
-        SolrService.delete_by_id(self.id)
-        SolrService.commit
-      end
-    end
-```
-
-## What’s the relationship between Blacklight and SolrMarc?
-
-However, one excellent way to index lots of MARC records into Solr quickly is to use SolrMarc. Some of the same people are active in both projects, e.g, Bob Haschart from UVA and Naomi Dushay from Stanford University. SolrMarc is not a Blacklight-specific project, it is also used by VuFind and other projects, and is a separate project that exists in its own right.

data/doc/Internationalization.md

@@ -1,32 +0,0 @@
-Blacklight uses the [Rails i18n framework](http://guides.rubyonrails.org/i18n.html) to provide multilingual version of most text in the Blacklight default templates. Blacklight ships with a set of English and French translations in [config/locales](https://github.com/projectblacklight/blacklight/blob/master/config/locales/).
-
-In addition to multilingual support, developments can also e.g. customize the English strings in Blacklight-based applications, which provides a way to change text without overriding templates and partials.
-
-## A quick i18n example
-A locale entry that looks like this:
-
-```yaml
-en:
-  blacklight:
-    application_name: 'Blacklight'
-```
-
-Is referenced in the Blacklight code as:
-
-```ruby
-I18n.t 'blacklight.application_name'
-# OR
-t('blacklight.application_name')
-```
-
-You could override this in your application's ```config/locales/en.yml```:
-
-```yaml
-en:
-  blacklight:
-    application_name: 'My Blacklight Application'
-```
-
-And then everywhere Blacklight views show the application name, it will use your label ("My Blacklight Application") instead of ours ("Blacklight").
-
-There are other i18n tricks (that we use) covered in the [Rails i18n Rails guide|http://guides.rubyonrails.org/i18n.html], including pluralization, interpolation, etc.

data/doc/JSON-API.md

@@ -1,83 +0,0 @@
-Blacklight's search, show and facets have JSON responses. The default serializations are very basic, but should be enough to drive simple AJAX widgets.
-
-### Search results
-`/catalog.json?search_field=all_fields&q=auckland`
-
-```json
-{
-  "response":{
-    "docs":[
-      { "title_display":"Maine",
-        "id":"2009002583",
-        "author_display":"Dornfeld, Margaret",
-        "format":"Book",
-        "isbn_t":["9780761447269"],
-        "published_display":["New York"],
-        "lc_callnum_display":["F19.3 .D67 2011"],
-        "subject_geo_facet":["Maine"],
-        "pub_date":["2011"],
-        "language_facet":["English"],
-        "material_type_display":["p. cm"],
-        "score":9.667667},
-     {"title_display":"Ghostly lighthouses from Maine to Florida","id":"2005005219","author_display":"Monks, Sheryl, 1967-","format":"Book"},
-        ...
-       ],
-    "pages": {  
-      "current_page":1,
-      "next_page":2,
-      "prev_page":null,
-      "total_pages":7,
-      "limit_value":10,
-      "offset_value":0,
-      "total_count":61,
-      "first_page?":true,
-      "last_page?":false
-    }
-  }
-}
-```
-
-### Facet list
-`/catalog/facet/subject_topic_facet.json`
-
-```json
-{
-  "response": {
-    "facets": {
-      "offset":0,
-      "sort":"count",
-      "items": [ 
-         {"value":"Book","hits":9737}, 
-         {"value":"Unknown","hits":88}
-      ],
-      "has_next":false,
-      "has_previous":false,
-      "limit":20
-    }
-  }
-}
-```
-
-### Single record
-`/catalog/2009002600.json`
-
-```json
-{
-  "response":{
-    "document":{
-      "title_display":"Nebraska",
-      "id":"2009002600",
-      "author_display":"Bjorklund, Ruth",
-       ....
-     }
-  }
-}
-```
-
-The JSON serialization can be overridden in a local application by providing alternative implementations of:
-  * `render_search_results_as_json`
-  * `render_facet_list_as_json`
-
-in your CatalogController.
-
-See: https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/catalog.rb#L175-L191

data/doc/Pagination.md

@@ -1,52 +0,0 @@
-Blacklight uses [kaminari](https://github.com/amatsuda/kaminari) for providing pagination of Solr responses. 
-
-One motivation for this is so a pagination view theme can be provided that you can use for your custom code with ordinary ActiveRecord or anything else kaminari can handle, to have consistency between the rest of your app's pagination and Blacklight's Solr response pagination. 
-
-## How it works
-
-The Blacklight response objects are Kaminari-ready #paginate, so you could call:
-
-    paginate(@response )  # where @response is an RSolr::Response
-
-Or, 
-    paginate @response, :theme => 'blacklight'
-
-![Blacklight theme](https://f.cloud.github.com/assets/111218/2059081/97fe4082-8b95-11e3-9fd2-ae824bcf7b7e.png)
-
-The `theme => 'blacklight'` part will be passed through kaminari, and tell kaminari to use the theme that the Blacklight plugin supplies at [app/views/kaminari/blacklight](https://github.com/projectblacklight/blacklight/tree/master/app/views/kaminari/blacklight)
-
-Any other arguments of ordinary kaminari paginate can also be passed in there.
-
-Additionally, we sometimes want to output a "X through Y of N" message with some basic pagination controls, which kaminari doesn't have a (good) way to do by default. Blacklight provides a simple partial to provide this behavior:
-
-```ruby
-  render partial: 'catalog/paginate_compact', object: @response
-```
-
-Or, using all kaminari-native methods:
-
-```erb
-<%= paginate paginate_compact, :page_entries_info => page_entries_info(paginate_compact), :theme => :blacklight_compact %>
-```
-
-![Compact](https://f.cloud.github.com/assets/111218/2059080/97fc3ee0-8b95-11e3-8c66-ab31dcd7eedb.png)
-
-## Changing the kaminari theme
-
-If you want to change how pagination links are rendered, the easiest/cleanest thing to do is to over-ride the 'blacklight' theme that the Blacklight plugin defines. Copy the view templates in Blacklight source at app/views/kaminari/blacklight to your own local app/views/kaminari/blacklight.  You actually only need to copy files you'll want to modify, templates not overridden with a local copy will still be found by kaminari from the Blacklight gem.  You can use any techniques available for creating a kaminari theme when editing these files, including over-riding more kaminari view templates if available. See the kaminari documentation. 
-
-There are other ways you could change how Blacklight pagination renders, but by doing it this way, any code (in core Blacklight or additional plugins you install) that tries to render pagination using kaminari with 'blacklight' theme will get your locally defined theme. 
-
-## Changing the default kaminari pagination options
-
-Sometimes you you just want to tweak a few things with pagination and it doesn't require crawling into the RSolr response or creating a kaminari theme. Here's how you do that.
-
-First, generate the kaminari config initializer:
-
-    rails g kaminari:config
-
-You will get a file in config/initializers/kaminari_config.rb that is mostly commented out.  The config options are mostly self-explanatory, but let's say that you don't like that Blacklight gives you 4 pages of links on either side of the current page.  Uncomment: 
-
-    # config.window = 4
-
-and change 4 to whatever number is preferable. More information on the kaminari general configuration options is available here: https://github.com/amatsuda/kaminari#general-configuration-options