Bug 7669 - Search Results Multiple Cover Image HTML & CSS
Summary: Search Results Multiple Cover Image HTML & CSS
Status: RESOLVED DUPLICATE of bug 26933
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-07 22:23 UTC by Shane Sammons
Modified: 2022-08-22 03:30 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Patch of my changes to opac_results.tt and opac.css (6.49 KB, patch)
2012-03-07 22:23 UTC, Shane Sammons
Details | Diff | Splinter Review
Bug 7669: Add CSS classes to OPAC results thumbnails (8.33 KB, patch)
2012-03-10 22:49 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 7669: Add CSS classes to OPAC results thumbnails (9.03 KB, patch)
2013-01-01 23:27 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Shane Sammons 2012-03-07 22:23:20 UTC Comment hidden (obsolete)
Comment 1 Liz Rea 2012-03-08 19:21:05 UTC
Changing to needs Signoff. 

Shane, how best do we go about testing this?
Comment 2 Shane Sammons 2012-03-08 19:53:36 UTC
If you use the OPAC CSS editing (Home › Administration › System Preferences > OPAC > OPACUserCSS )  section and use the .thumbnail class or the classes I added:

.opac_thumb, .amazon_thumb, .google_thumb, .syndetics_thumb, .openlibrary_thumb, .bakertaylor_thumb (for thumbnails)

.amazon_no, .google_no, .openlibrary_no, .bakertaylor_no (for no-image)

Additionally to save time putting the following in the OPAC CSS editor will give you a setup similar to my screencast:

/*examples how a specific class works*/
div.amazon_no{ /*Amazon no image [seem broken in code]*/
border: 1px solid #FFA500; /*amazon is ornage*/
}
.google_thumb, .google_no{/*Google no image*/
border-top: 2px solid #F00;
border-right: 2px solid #080;
border-bottom: 2px solid #FF0;
border-left: 2px solid #00F;
padding: 2px;
}
.openlibrary_no{
background: url(http://openlibrary.org/images/logo_IA-sm.png) right center no-repeat;
color: #00F;
text-align: left;
}

Hopefully that explains how to try it?
Comment 3 Jared Camins-Esakov 2012-03-10 22:49:27 UTC Comment hidden (obsolete)
Comment 4 Ian Walls 2012-03-19 16:03:21 UTC
Template only change to opac-results.tt and CSS.  Resulting HTML looks much cleaner and easier to work with.  Marking as Passed QA.
Comment 5 Paul Poulain 2012-03-20 14:16:30 UTC
sorry but the patch doesn't apply anymore. The .css conflict is easy to solve, but the .tt isn't, so switching to "does not apply".

Sorry
Comment 6 Chris Cormack 2013-01-01 23:27:08 UTC Comment hidden (obsolete)
Comment 7 Chris Cormack 2013-01-01 23:27:45 UTC
Rebased the patch, it now applies, I have not tested it works, I made some changes to get it to apply so someone other than me needs to sign off.
Comment 8 Owen Leonard 2013-01-03 15:59:15 UTC
I can see that at the very least this patch breaks local cover images on the results page. Unfortunately the amount of changes in the patch make it difficult to debug. I think the relevant changes could be made in a new patch without touching so many lines.
Comment 9 Owen Leonard 2013-01-03 16:05:16 UTC
The local cover images JavaScript tries to pull the biblionumber from the class of the #local-thumbnail <div>. Other classes have been added to that <div>, so the value is getting polluted.
Comment 10 Marc Véron 2016-05-23 15:14:06 UTC
Is this bug still valid or can it be marked as RESOLVED
Comment 11 Owen Leonard 2016-05-23 15:27:22 UTC
I think the goals of the original patch could still be seen as useful. The display of cover images could be made more consistent. Since the original patch author never chose to follow up I think the best thing to do is return this to "New."
Comment 12 Liz Rea 2019-04-11 14:21:46 UTC
Coce kind of solves this by handling the cover selection in a different place, do we still want to deal with this in js/css?

probably still relevant for local covers?
Comment 13 Lucas Gass 2021-05-06 19:56:36 UTC
(In reply to Liz Rea from comment #12)
> Coce kind of solves this by handling the cover selection in a different
> place, do we still want to deal with this in js/css?
> 
> probably still relevant for local covers?

I think this is still relevant for local covers, Syndetics, or any other non-Coce image services.
Comment 14 David Cook 2022-08-22 03:30:19 UTC

*** This bug has been marked as a duplicate of bug 26933 ***