EncyclopediaOfLife/eol — comment on commit ef7b6563f13254bf99b4ecb17943ef29ce61e2a1
File:  line 0
By lwalley:

I like the idea of capturing the original parameters, that could be done in a before_filter with presumably little overhead, and then the generation of the href can be done later with a helper method and only when required.

I think url_for is an option but it can give different results if our routes are not consistent, for example we send both :id and :q parameters to the search controller and so depending on which parameter is sent to url_for it will produce different routes e.g. with a query string "tiger" we might have /tiger/ search/tiger /search/index/tiger or /search?q=tiger or /search/?q=tiger.

This impacts our internal linking as will_paginate uses url_for and so the links it generates vary depending on the route used. SEO recommendation is to ensure our internal links point consistently to our preferred URLs and even the difference of /search/?q= versus /search?q= (i.e. the extra slash is not ideal). One way to control the results for url_for is to manipulate the params that we send to it e.g. in the case of the search controller replace params[:id] with params[:q] before sending them to will_paginate this will more consistently produce the pagination links /search?q=tiger or /search/?q=tiger rather than /search/index/tiger or something, but there still appear to be discrepancies with the number of slashes between the request URL and the ones produced by will_paginate, so unless we can make our routes more consistent or override will_paginate use of url_for there is only so much we can fix by manipulating the params.

I've had feedback regarding pagination that we should use rel=next and rel=prev so presumably in order to calculate those hrefs we'll need to define them after or at the end of the controller action i.e. after the paginated record sets have been defined. So I think storing the original params first and then determining the correct hrefs using url_for or some other method from the views is a good idea.