Bug 5761 - system preference to control "No cover image available" message
Summary: system preference to control "No cover image available" message
Status: RESOLVED DUPLICATE of bug 13597
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Owen Leonard
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-15 01:46 UTC by Reed Wade
Modified: 2019-07-01 11:53 UTC (History)
4 users (show)

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


Attachments
pic showing FAILING CSS solution (161.54 KB, image/png)
2015-10-30 05:21 UTC, Mason James
Details
pic showing FAILING JS solution (165.72 KB, image/png)
2015-10-30 05:51 UTC, Mason James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Reed Wade 2011-02-15 01:46:00 UTC
If cover art is not available for an item, an informative but unattractive "No cover image available" message is given.

It would be nice if there was a system preference setting to silence this and show nothing in place of the message in those cases.
Comment 1 Reed Wade 2011-02-15 01:46:53 UTC
.. and no message border -- just whitespace
Comment 2 Owen Leonard 2011-09-20 15:20:31 UTC
How about this in OPACUserCSS:

span.no-image {
    display: none;
}
Comment 3 Owen Leonard 2012-03-06 15:36:04 UTC
Given the OPACUserCSS workaround I'm going to consider this WONTFIX. If anyone wants to argue please re-open.
Comment 4 Mason James 2015-10-30 05:15:00 UTC
(In reply to Owen Leonard from comment #2)
> How about this in OPACUserCSS:
> 
> span.no-image {
>     display: none;
> }

(In reply to Owen Leonard from comment #3)
> Given the OPACUserCSS workaround I'm going to consider this WONTFIX. If
> anyone wants to argue please re-open.

I just confirmed this CSS does not work for OPAC, with 'GoogleJackets' syspref enabled,
on Koha 3.18.8

so, re-opening - can someone else confirm this please?
Comment 5 Mason James 2015-10-30 05:21:35 UTC
Created attachment 44182 [details]
pic showing FAILING CSS solution
Comment 6 Mason James 2015-10-30 05:46:35 UTC
(In reply to Mason James from comment #4)
> (In reply to Owen Leonard from comment #2)
> > How about this in OPACUserCSS:
> > 
> > span.no-image {
> >     display: none;
> > }
> 
> (In reply to Owen Leonard from comment #3)
> > Given the OPACUserCSS workaround I'm going to consider this WONTFIX. If
> > anyone wants to argue please re-open.
> 
> I just confirmed this CSS does not work for OPAC, with 'GoogleJackets'
> syspref enabled,
> on Koha 3.18.8

..also, for me, the JS solution described below does not work either

 http://wiki.koha-community.org/wiki/JQuery_Library#Show_nothing_when_cover_images_are_not_found
Comment 7 Mason James 2015-10-30 05:51:44 UTC
Created attachment 44183 [details]
pic showing FAILING JS solution
Comment 8 David Cook 2015-10-30 06:03:07 UTC
Mason: Can you explain why Owen's CSS doesn't work for you?

I've been using the CSS mentioned by Owen for a few years now and I haven't noticed any difficulties. Does Google Jackets use a different HTML element and/or class?
Comment 9 Mason James 2016-04-20 23:35:00 UTC
(In reply to David Cook from comment #8)
> Mason: Can you explain why Owen's CSS doesn't work for you?
> 
> I've been using the CSS mentioned by Owen for a few years now and I haven't
> noticed any difficulties. Does Google Jackets use a different HTML element
> and/or class?

for intranet search results, the amazon 'no image' element is not a 'no-image' class, so the following CSS will not work...

span.no-image {
    display: none;
}

here is an example of the element
<a class="p1" href="/cgi-bin/koha/catalogue/detail.pl?biblionumber=7327">
 <img src="https://images-na.ssl-images-amazon.com/images/G/01/x-site/icons/no-img-sm.gif" alt="" class="thumbnail">
 </a>

observed on Koha 3.20.06
Comment 10 Mason James 2016-04-20 23:37:40 UTC
(In reply to Mason James from comment #9)
> (In reply to David Cook from comment #8)
> > Mason: Can you explain why Owen's CSS doesn't work for you?
> > 
> > I've been using the CSS mentioned by Owen for a few years now and I haven't
> > noticed any difficulties. Does Google Jackets use a different HTML element
> > and/or class?
> 
> for intranet search results, the amazon 'no image' element is not a
> 'no-image' class, so the following CSS will not work...

but some good news, the CSS *does* seem to work for a GBK 'no-image' element
so, apologies there :)
Comment 11 Mason James 2016-04-20 23:49:59 UTC
(In reply to Mason James from comment #9)
> (In reply to David Cook from comment #8)
> > Mason: Can you explain why Owen's CSS doesn't work for you?
> > 
> > I've been using the CSS mentioned by Owen for a few years now and I haven't
> > noticed any difficulties. Does Google Jackets use a different HTML element
> > and/or class?
> 
> for intranet search results, the amazon 'no image' element is not a
> 'no-image' class, so the following CSS will not work...

hmm, the no-image jscript code in the intranet, does not add the 'no-image' class
- unlike the OPAC version
Comment 12 Mason James 2016-04-21 00:52:19 UTC
(In reply to Mason James from comment #11)
> (In reply to Mason James from comment #9)
> > (In reply to David Cook from comment #8)
> > > Mason: Can you explain why Owen's CSS doesn't work for you?
> > > 
> > > I've been using the CSS mentioned by Owen for a few years now and I haven't
> > > noticed any difficulties. Does Google Jackets use a different HTML element
> > > and/or class?
> > 
> > for intranet search results, the amazon 'no image' element is not a
> > 'no-image' class, so the following CSS will not work...
> 
> hmm, the no-image jscript code in the intranet, does not add the 'no-image'
> class
> - unlike the OPAC version

i've added a patch for this here...
 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13597

i think Owens CSS solution might work, after this patch is added :)
Comment 13 Nick Clemens (kidclamp) 2019-07-01 11:53:59 UTC
Seems discussion is that we need consistent links and then CSS works here, making this a duplicate of 13597 to allow that to resolve this

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