show back to search and start over for 1 result show pages

[mejackreed]

This pull request modifies a show page to include the "Back to Search" and "Start Over" buttons from a navigated search that only includes 1 search result. Previously both the pagination and search buttons were both inside #previousNextDocument and only shown if @previous_document || @next_document. I think this logic should be decoupled and that these are separate concerns.

GeoBlacklight usability testing indicated not showing "Back to Search" and "Start Over" on every show page navigated from a search was confusing for users. It also was not clear to users why this was happening.

[cbeer]

Can you fix the indentation in this file? it seems a little screwy (and probably not really your fault.)

[mejackreed]

screwy for sure... force pushed

[cbeer]

While you're touching this file... want to change this line:

<%= link_to t('blacklight.search.start_over'), start_over_path(current_search_session.try(:query_params) || {}), id: "startOverLink", class: 'btn'  %>

[jcoyne]

Yes, this is a good idea.

[jrochkind]

Changing the HTML DOM id from #previousNextDocument to #paginationSearchWidgets will be a backwards compatibility issue for anyone with local CSS styling using that HTML id. (I do!).

If you're going to go all the way to backwards incompat -- is there any reason this is styled with an id instead of a class anyway? Using an id means there can only be one per page without it being technically illegal HTML, conceivably someone might sometimes want more than one on a page (top and bottom or something).

Change to a class?

Or, hey, best of both worlds -- leave the id the same, #previousNextDocument for backwards compat, but add a class .pagination-search-widgets, BL CSS will reference the class not the id. ID still there for backwards compat, but BL uses the better name, applied as a class not an ID.

?

[mejackreed]

@jrochkind I'm ok with your suggestion for backwards compatibility, with a comment to remove id selectors in Blacklight 6

[mejackreed]

Ok so now updated with @jrochkind s suggestion for backward compatibility with deprecation notice.

[cbeer]

I think this unconditional deprecation warning will get annoying really fast. Can we either leave a comment (or comment out the block) instead, and remember to include it in release notes when we kill the id?

[mejackreed]

@cbeer added as a comment

[cbeer]

👍