Content Cafe can no longer retrieve cover images by UPC

Bug #1318029 reported by Kathy Lussier on 2014-05-09
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

Evergreen version 2.5.3b

Prior to 2.5, we were able to retrieve cover images by UPC from Content Cafe - see search results and record summaries on a 2.4 production system - http://evergreen.noblenet.org/eg/opac/results?fg%3Abasic=&query=brave+disney+presents+pixar+animation&qtype=keyword&locg=1

Starting with 2.5, we can no longer retrieve those images. See http://egtraining.noblenet.org/eg/opac/results?query=brave+disney+presents+pixar+animation&qtype=keyword&fg%3A=&locg=1&sort=

By reverting the changes made in http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=4408bff9b3cb2740b60b69b1ec2c1bf61691f1dc, we were able to make the images appear again on the record summary page. However, we should probably find a solution that allows us to retrieve a UPC from Content Cafe while maintaining the ability to use the new features that came with https://bugs.launchpad.net/evergreen/+bug/1065378.

Jeff Godin (jgodin) on 2014-05-09
Changed in evergreen:
assignee: nobody → Jeff Godin (jgodin)
Bill Erickson (berick) wrote :

ContentCafe doesn't differentiate between ISBN and UPC at the API level, so falling back to passing UPC should when no ISBN exists should suffice. Untested, but I believe this would work:

diff --git a/Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent.pm b/Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent.pm
index e1c0bf0..5ed3b8f 100644
--- a/Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent.pm
+++ b/Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent.pm
@@ -173,7 +173,7 @@ sub handler {
             $data = $handler->$method($keyhash);
         } else {
             # Pass single ISBN as a scalar to the handler
- $data = $handler->$method($keyhash->{isbn}[0]);
+ $data = $handler->$method($keyhash->{isbn}[0] || $keyhash->{upc}[0]);
         }
     } catch Error with {
         $err = shift;

Jason Stephenson (jstephenson) wrote :

Bill's fix above appears to work OK for us. It fixes most of our Content Cafe problems. However, we do believe it will break OpenLibrary because OpenLibrary only accepts ISBN.

I am attaching a patch that actually applies and makes another slight change of moving the return check for the missing keyhash values inside the try block. This adds another check, but makes them more specific to what we're looking for.

Along the way, we've discovered that Evergreen appears to be using the testing API for Content Cafe. Their integration guide suggests doing a lot of other things, including send all of the identifiers for a record at once.

We think the module ought to be refactored to take advantage of the full API, but of course there's always the question of tuits.

Tim Spindler (tspindler-cwmars) wrote :

We were still experiencing issues with Bill's patch and did not fix things entirely on a 2.5.3 install of evergreen. Specifically, some images are no longer showing not even with the filler "no cover image". We are reimaging the test server at the moment so we cannot currently test the new code.

Jason Stephenson (jstephenson) wrote :

We still get what Tim reports with the above patch. I just pretty much ignored it. I didn't expect to get a No Image Available file for every listing.

Jason Stephenson (jstephenson) wrote :

Actually, I should add that I only appear to be getting no image at all for items without an ISBN or UPC. That is, they have neither. If they have one or the other, I do get an image, even the "No Image" image.

Some ISBN data as commonly found in MARC can cause problems for Business::ISBN. I think this other bug referring to Syndetics might also apply in this case:

https://bugs.launchpad.net/evergreen/+bug/1302207/

Just tested 2.7.1 with Content Cafe and UPC lookup seems to work fine. I added a UPC 024 to a record. Restarted memcached and the image showed up like it should.

Kathy Lussier (klussier) wrote :

Thanks Josh! I do think it was fixed with some of the added content changes for 2.7, but, since those were new enhancements, the bug continues to occur in 2.6. Since 2.5 is no longer supported, we probably can't worry about backporting a fix there now.

Kathy Lussier (klussier) wrote :

Setting this to Won't Fix since the functionality is available in 2.7+ and 2.6 is no longer supported.

Changed in evergreen:
status: New → Won't Fix
assignee: Jeff Godin (jgodin) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers