Koha Blog

On every record’s detail page there is list of links in the right-hand sidebar for searching for that title on a few other sites: Worldcat, Google Scholar, and Bookfinder. These were chosen as reasonably generic choices for a wide audience. The trouble is, generic doesn’t work for everyone: For many libraries these links aren’t appropriate. They’d like to be able to take out one or more of them and/or add their own. Unfortunately these links are hard-coded in the template. Until someone contributes the time or money to develop a solution, we have to resort to JavaScript trickery to accomplish it.

JavaScript Trickery

jQuery to the rescue. If we use FireBug to inspect the page we can see that the “box” the links are in has a unique ID. That’s perfect as a place to tell jQuery to start looking.

Click for full screenshot

Let’s start by adding a custom link to this menu. We start our JavaScript by targeting the #further div. Since we want to add an item to the list contained within the #further div, we’ll add that to the selector:

$(document).ready(function(){
$("#further ul")...
});

And since we want to append some additional HTML, we’ll use append():

$(document).ready(function(){
$("#further ul").append("<li><a href=\"http://www.paperbackswap.com\">Paperbackswap.com</a></li>");
});

Okay, drop that into the opacuserjs system preference and refresh your OPAC page to see how it worked:

Updated list of links

Great! We’re done, right? Well… The trouble is, the link we added doesn’t include any means to pass the title to the search system on the other site. How are we supposed to do that? Luckily, many sites are very open in the way they perform search requests. You just have to do a little digging. Let’s go to Paperbackswap.com and do a search to see how they handle it. Since I know we’re going to pass a title to their search system, I’m going to look for a title-specific search. I found one on their advanced search page. Plug in a title and look at the resulting URL:

http://www.paperbackswap.com/book/browser.php?all_k=&not_k=&or_k[]=&or_k[]=&phrase_k1=cryptonomicon&all_ti=&not_ti=&or_ti[]=&or_ti[]=&phrase_ti1=&a=&i=&bd=&p=&g=0&b[]=Paperback&b[]=Audio+Cassette&b[]=Hardcover&b[]=Audio+CD&pd=&pd_type=e&r=n&s_type=a&l=10&sby=&oby=ASC

What a mess! But underneath all that junk there’s one bit of real functionality there:

http://www.paperbackswap.com/book/browser.php?all_k=&not_k=&or_k[]=&or_k[]=&phrase_k1=cryptonomicon&all_ti=&not_ti=&or_ti[]=&or_ti[]=&phrase_ti1=&a=&i=&bd=&p=&g=0&b[]=Paperback&b[]=Audio+Cassette&b[]=Hardcover&b[]=Audio+CD&pd=&pd_type=e&r=n&s_type=a&l=10&sby=&oby=ASC

It looks to me like phrase_k1=cryptonomicon is the meat of the search, and everything else is defaults. Let’s try the link this way and see if we get good results:

http://www.paperbackswap.com/book/browser.php?phrase_k1=cryptonomicon

Seems to work just as expected. Now we know that we can use a link like this to pass our own search term to the site:

http://www.paperbackswap.com/book/browser.php?phrase_k1=<title>

Using JavaScript to find the title

Click to enlarge screenshot

We’re building the custom search link with JavaScript, so we’ll have to find a way to leverage the same tool to grab the title.  Luckily there is a unique element on the page which contains the title, and we can grab it using jQuery: the <h1> tag. Okay, so there are two <h1>’s on the page, a little bit of a technical foul on Koha’s part. Using FireBug we can ispect the <h1> containing the title and we can see it is contained in a uniquely identified container. We can grab the contents of the heading this way:

$(document).ready(function(){

var title = $("#catalogue_detail_biblio h1").html();

});

Add this to code we wrote to add the custom link along with the search URL we puzzled out:

$(document).ready(function(){

var title = $("#catalogue_detail_biblio h1").html();
$("#further ul").append("<li><a href=\"http://www.paperbackswap.com/book/browser.php?phrase_k1="+title+"\">Paperbackswap.com</a></li>");
});

Notice we’re using + to concatenate the JavaScript variable with the markup that forms the link. Looks good, and the link works!

Our new link passes the correct title to the other site

…Until we come to a record which has a subtitle. For example, The return of the king: being the third part of The lord of the rings

You got markup in my content!

The problems arises because the subtitle is marked up with a <span> inside the
<h1>. When we grabbed the contents of the <h1> tag, we also got the <span>. We’ll have to do some more JavaScript trickery to drop the <span>. Here’s what I came up with, thanks in part to this demo:

$(document).ready(function(){

var orig = $("#catalogue_detail_biblio h1").remove("span").html();
var regexp = new RegExp ("<span[^.]*\/span>", "gi");
var title = orig.replace(regexp,"");
$("#further ul").append("<li><a href=\"http://www.paperbackswap.com/book/browser.php?phrase_k1="+title+"\">Paperbackswap.com</a></li>");

});

Now we’re getting just the title, and we’re getting the correct link. Success.

This question came up on the Koha mailing list today: How can I add a Koha login form to my library’s web site? Luckily it’s really simple. The image here is of the one we added one to our site.

Everything you need to know about how to do it is right on your Koha OPAC home page. Just view the source for the login box and copy it! Here’s the simple version, adapted right from the source:

<form method="post" action="http://path.to.your.opac/cgi-bin/koha/opac-user.pl">
<input type="hidden" value="opac" name="koha_login_context"/>
<label for="userid">Login:</label><input type="text" name="userid" id="userid"/>
<label for="password">Password:</label><input type="password" name="password" id="password"/>
<input type="submit" value="Log In"/>
</form>

The only thing you’d need to change to make that snippet work for you is the path.to.your.opac part. Replace that with the full URL of your Koha OPAC, e.g. http://acpl.kohalibrary.com.

You could even do the same for the staff client, for instance if you wanted your users to be able to log into the Koha staff client from your library’s intranet:

<form method="post" action="http://path.to.your.staff.client">
<input type="hidden" value="intranet" name="koha_login_context"/>
<label for="userid">Username:</label><input type="text" id="userid" name="userid"/>
<label for="password">Password:</label><input type="password" id="password" name="password"/>
<input type="submit" value="Log in" />
</form>

Of course I wouldn’t recommend putting a login form for your staff client anywhere in public view. Note that using that form will log you in to your default library. If you wanted to give your users the option of logging into a different library you’d have to reproduce the full <select> tag from your staff client’s login page.  View the source to find it.

One of the custom reports I’ve been using recently is one that shows me the most expensive items in the catalog. I’m not trying to figure out which book to sneak out under my coat, I’m trying to find data-entry errors which might cause problems for the patrons.

You lost that paperback? That’ll be $4399.00.

The trouble is, once I’m cruising through this report making corrections I’m quickly frustrated by the interface for adding items.

The list of items is in its own container with the css property “overflow:auto” so that if it exceeds the constraints of the container it’s in it will display scrollbars. It always displays scrollbars. You have to scroll to the right to see the item’s replacement price, then back to the left to find the Edit link. And it’s hard to be sure you clicked the Edit link in the correct row, because once you’re at the Edit link you can’t see the price anymore!

What if we could access the Edit and Delete functions from anywhere in the row? Inspired by WordPress’s inline edit menu I worked up this example:

Try navigating anywhere in the table of item details and clicking a table cell. You’ll see Edit/Delete links appear for that row. Implementing this change would allow the user to jump to the Edit or Delete functionality from anywhere in the table eliminating the need to scroll back and forth for the static links.

The advantage to the method used in this example is that it’s simple: no generating tooltips or modal dialogs, just a simple append of the Edit|Delete links to the table cell which gets clicked.

$("td").click(function(event){
var $tgt = $(event.target);
if($tgt.is("a")||$tgt.is(":first-child")||$tgt.is(":nth-child(2)")){ return true; } else {
var rowid = $(this).parent().attr("id");
num_rowid = rowid.replace("row","");
$(".linktools").remove();
$(this).append("<span class=\"linktools\"><a href=\"/path/to/additem/script.pl?op=edititem&amp;amp;biblionumber="+biblionumber+"&itemnumber="+num_rowid+"\">Edit</a> | <a href=\"/path/to/additem/script.pl?op=delitem&amp;amp;biblionumber="+biblionumber+"&itemnumber="+num_rowid+"\" onclick=\"confirm_deletion("+biblionumber+","+num_rowid+"); return false;\">Delete</a></span>");
}
});

The disadvantage to the resulting UI is that it could suggest to the user that clicking Edit or Delete will edit or delete just the contents of that cell, which is of course incorrect. It wouldn’t be good for a librarian to expect a click on “Delete” to delete, for instance, only the value contained in the replacementprice field and find that the entire item had been deleted.

I’m not sure how to mitigate that confusion while retaining the script’s simplicity.

Update: Here’s an alternate, slightly more verbose version.

Does your library have too many choices on the OPAC’s advanced search page? From the point of view of our librarians we don’t, but I think from the point of view of the patrons we do. 43 choices? And many of those categories encompass the same materials or genres. You could easily group our categories using format, audience, or other criteria:

• DVDs: DVD, DVDJ, DVJN, DVDN
• Videos: AV, AVJ, AVJN, AVNF
• Movies: DVD, DVDJ, DVJN, DVDN, AV, AVJ, AVJN, AVNF
• Books for adults: AF, MYS, SCI, WES, LP, LPNF, PB, BIO, NF
• Large Print: LP, LPNF

It’d be great if you could define “category groups” in Koha to allow patrons to easily search multiple categories at once. Until that comes about, how can we approach the problem from the front end?

Selecting Multiple Categories with JavaScript

Here’s a little experiment I worked up. This is just a static example page to demonstrate the selections.  Some parts of the OPAC omitted for simplicity.

Try clicking the links at the top of the category table. Clicking “Books” will select all collection codes which I’ve defined as a book for adults. Clicking “Audio Books” will select any category which could be defined as an audio book, whether it be on CD, cassette, or Playaway.

All the functionality of this example could be layered on top of the OPAC using existing avenues for customization like the opacuserjs system preference. It’s not very efficient to set up, however, because you have to hard-code all your collection codes within the JavaScript. That means that you have to update your script any time you add a category.

var books = "#ccode-1,#ccode-5,#ccode-12,#ccode-13,#ccode-14,#ccode-15,#ccode-16,#ccode-17,#ccode-18,#ccode-19,#ccode-27";
var movies = "#ccode-2,#ccode-3,#ccode-4,#ccode-6,#ccode-23,#ccode-39,#ccode-40,#ccode-41";
var lp = "#ccode-13,#ccode-14";

Defining your “supercategories” could be as difficult as defining your original categories in Koha. What criteria do you use? Audience? Format? Content? In my example I mix all three. Would that be confusing to patrons? I may yet add this to our OPAC, but I’ll have to ponder these issues a little more.

The OPAC’s Cart and Lists buttons are an unusual construction. Their appearance is the result of a rather convoluted combination of CSS and HTML designed to give nice anti-aliased, rounded corners and flexibility when the text is resized.  Try increasing the font size in your browser (Ctrl +).

The technique to create these buttons was adapted from Scalable CSS Buttons Using PNG and Background Colors.  If you’re interested in understanding the real nuts and bolts of the technique I suggest you read through that article. I’m going to cover just the details we need to look at for customizing the default appearance in Koha. [Edit: The link no longer works, sorry.]

There are several options we need to cover when changing the buttons’ appearance:

1. The link and link hover color
2. The button background-color (default and hover)
3. The button border

The Cart and Lists buttons each have their own ID in the HTML for reference in the CSS: #cartmenulink and #listsmenulink. Let’s look at the Lists button for simplicity’s sake.

1. The link color

The link color is the most straightforward one: Target the A element with the #listsmenulink ID:

a#listsmenulink { color: #E5CCE6; }
a#listsmenulink:hover { color: #FF99FF; }

2. The button background-color (default and hover)

The buttons have both a default background color and a hover background color. Set them by targeting the #listsmenulink ID:

#listsmenulink { background-color : #6600CC; }
#listsmenulink:hover { background-color : #9900CC; }

If we’re just changing background colors, and not images, on the button, how is it possible that we get a nice gradient? The answer is in this part of the default CSS:

#listsmenulink[class] {
background-image : url(../../images/button-background-gradient.png);
background-position : left top;
}

That’s a PNG file with alpha transparency. It overlays the solid background color and softens it with a gradient. If you like the gradient you can leave this part of the CSS without overriding it in your custom stylesheet. It will work with whatever background color you specify. If you want to turn it off to have a solid-color button, use this:

#listsmenulink[class] {
background-image: none;
}

3. The button border

Changing the button border is the trickiest step because it requires an image editor. The button border consists of a single background-image:

How the button would appear if the border image had transparent corners

The image gives the button its border color. The center of the image is transparent. The corners are opaque, colored to match the blue of the default background of the search bar. The corners have to be opaque because they have to mask the square corners of the HTML element behind them.

Changing the background color means the corners no longer match what is behind them

The fact that the corners are colored to match the default background means that if you try to change that background color your buttons will no longer match.

At the moment the only solution for those wishing to make changes to the button background is to recreate it from scratch. I’d like to share the source files I’m using so that in the future it’s easier for Koha users to make this change themselves. I use Photoshop 7 much of the time (yes I know it’s old), so I’m offering that version. I also recreated the graphic in Fireworks MX (again, old) and Inkscape .046 (yay, up to date!).

Whatever program you use to edit these files, there are two basic steps to achieve the right look:

1. Edit the stroke of the button shape (the border color).
2. Change the color of the opaque corners.

Our edited button background image gives us corners that blend perfectly with our custom background color.

After your file is edited to your satisfaction the next step is to export it in a web-friendly format:

• If you’re using Photoshop use File > Save for Web and choose PNG-24 with the Transparency option checked.
• In Fireworks, your Optimize setting should be PNG32 with the transparent matte option chosen.
• In Inkscape, use the Export Bitmap option to export the Drawing only. In my tests Inkscape exported the 32-bit version (the version with alpha transparency) by default.

What About Internet Explorer 6?

Users of Internet Explorer 6 will see a solid-color button with square corners.

One major downside of this method of styling the buttons is that it doesn’t work properly in Internet Explorer 6. IE6 doesn’t support PNG files with alpha transparency. The good news is that users of IE6 will still get a usable button. The bad news is that it won’t be very pretty.

Options Going Forward

If we’re already excluding users of Internet Explorer from the rounded button experience, why not use pure-CSS rounded corners? We could eliminate all the time and effort demonstrated in this article with some simple [if proprietary] CSS. Something like this:

#cartmenulink,#listsmenulink {
color: #336600;
padding: .7em .9em .7em .8em;
margin: .5em .5em .5em 1.5em;
text-decoration:none;
-moz-border-radius: 7px;
-webkit-border-radius: 7px;

}
#cartmenulink {
border:1px solid #336699;
background: #93d869 url("../../images/cart-button-background.png") top left repeat-x;
}
#listsmenulink {
border:1px solid #006699;
background: #9FBFFF url("../../images/lists-button-background.png") top left repeat-x;
}

This works fairly well in Firefox, Safari, and Chrome. Unfortunately, it fails not only in Internet Explorer 6, 7, and 8, but all versions of Opera too. For the time being, our more-complex process gives the desired result to a wider audience.

Using *-border-radius to style rounded corners. Click to view full-size.

I got a question yesterday on the Koha IRC channel about changing the background of message which appear onscreen during check-in operations. Aparently librarians were not noticing the messages, and the questioner wondered if those messages could be styled in a different way.

Koha prompts the user to return an item to its home library with a message box

It’s possible to customize Koha’s staff client just like it’s possible to customize the OPAC. At the moment, though, the staff client lacks one useful option: a means of injecting custom inline CSS as we can with OpacUserCSS. The staff client does have intranetuserjs, and that gives us an opportunity to get around the shortcoming.

PLEASE NOTE: As the manual says, “IMPORTANT: This system preference is an advanced option. If you enter a value with incorrect syntax you can make it very difficult to access the staff interface.”

Here’s how intranetuserjs gets added to the markup. From the template:

<!-- TMPL_IF NAME="intranetuserjs" --><script type="text/javascript">
//<![CDATA[
<!-- TMPL_VAR NAME="intranetuserjs" -->
//]]>
</script><!-- /TMPL_IF -->

IF the intranetuserjs system preference has anything in it, the template will include it, wrapped in the appropriate <script> tags. Here’s how we’ll bend the rules to get our custom CSS in: Add this to the intranetuserjs pref:

//]]>
</script>
<style type="text/css">
/* Insert custom styles here */
</style>
<script type="text/javascript">
//<![CDATA[

When we add that to the intranetuserjs preference, Koha generates this markup in the template:

<script type="text/javascript" >
//< ![CDATA[
//]]>
</script>
<style type="text/css">
/* Insert custom styles here */
</style>
<script type="text/javascript">
//<![CDATA[
//]]&gt;
&lt;/script&gt;

The first thing we do is close the <script> tag which was automatically opened by the template, which expected us to add JavaScript content. We add our custom <style> tag, then re-open the <script> tag. The template is going automatically add a closing <script> tag, so we’ve got to add an opening one or risk breaking things.

With that in place we can add our custom CSS. The message box gets its background from an image. The simplest way to customize its appearance is to remove the image and add a custom color:

div.message { background: #CCFF00 none; }

Remove the background image and add a custom color

Or use your own background image:

div.message { background:white url(http://www.myacpl.org/koha/wp-content/uploads/2009/07/squidfingers-pattern_141.gif) scroll left 0;
}

Eye-catching but not very readable!

If you’re going for really eye-catching, you’ll have to go for an animated background image!

If you find a background image you like, remember: copy the image to your own server. Don’t hot-link it from someone else’s. Nefarious webmasters are likely to swap out the image for something you don’t want to see!

Of course I don’t really recommend that you use an animated background. As you’re approaching this kind of change, please remember: changing the style of Koha’s default message box will change all instances of that style box. Koha re-uses that style for displaying informational messages throughout the interface. The staff at the circulation desk may like it, but the cataloger doing MARC imports may not!

I often hear people ask if they can have their book covers on the left-hand side of the search results list. This is one of the aspects of Koha 2.x that some people miss. Because the search results are in a table, you can’t simply change something in the CSS to move the images to the other side of the screen. Without changing the template itself, what can we do?

Usually my response is live with it, but it occurred to me yesterday that jQuery could handle this:

$(document).ready(function(){
$(".searchresults tr td:last-child").each(function () {
$(this).prependTo($(this).parent());
});
});

After the standard leading “(document).ready” stuff, the script starts by looking for elements inside anything with a class “searchresults.” That’s a <div> that surrounds the search results table. We’re looking for any <td> which is the “last child” of a <tr>. That is, the last table cell in each table row. jQuery’s each() function lets us loop over each instance of those last-child <td>’s that we find and perform some action on it.

$(this).prependTo($(this).parent());

This is the action we’re performing for each <td> our script matches. “$(this)” is how we identify the matched <td>. Then we use the prependTo() function to “cut” that <td> and “paste” it at the beginning of the row. Notice the element we’re prepending to is “$(this).parent().” parent() selects the element which “contains” $(this): <tr> contains <td>, so we’re moving our <td> to the beginning of the row.

Paste the script into your opacuserjs system preference and try a search. It works in my test, but don’t take my word for it. Test carefully and let me know if you see any problems with it.

This post was my way to “talk out” the issues I wanted to cover for my presentation at KohaCon 2009. Some of it consists of condensed versions of other posts already on the site, so please take a look around at the other stuff I’ve posted. — Owen

(more…)

On of the options we have for customizing Koha’s OPAC is to add a custom menu to the left-hand column. Just like with the opacheader preference, this is done by adding HTML markup to a system preference: OpacNav (Koha has an annoying lack of consistency when it comes to system preference capitalization).

If you’ve just installed Koha for the first time there is probably some default text in your OpacNav preference, “Important links here.” This bit of example content might lead to questions like “Important links where?,” but it’s just a way to point out one of your customization options. If you delete the contents of OpacNav, the left-hand column will go away on most pages. The exception is the facets column on the search results page and menus on user pages when you’re logged in.

The Athens County Public Libraries OPAC has no OpacNav content for a couple of reasons: First, our site-wide navigation is in the horizontal menu in the OPAC header; Second, having a resident left-hand sidebar takes up valuable screen real estate. I’d rather be able to give plenty of room for the content the user is looking for.

Other libraries choose to add content to the OpacNav preference because it fits their users’ expectations (as it did ours in our previous designs). Luckily OpacNav is just as flexible as opacheader in terms of creating the look and feel you want.

Creating the custom menu

OpacNav is even easier than opacheader because its position in the template doesn’t lead to any float/clearing problems like we saw in the opacheader article. Let’s start again at Listamatic for a good self-contained vertical list design. I’m going to pick a fairly simple one: Bieler Batiste’s list. The HTML gets pasted into the OpacNav preference:

<div id="navcontainer">
<ul id="navlist">
<li id="active"><a href="#" id="current">Item one</a></li>
<li><a href="#">Item two</a></li>
<li><a href="#">Item three</a></li>
<li><a href="#">Item four</a></li>
<li><a href="#">Item five</a></li>
</ul>
</div>

Paste the CSS into your custom stylesheet (specified in opaccolorstylesheet) or paste it into the OPACUserCSS preference:

#navlist li
{
display: inline;
/* for IE5 and IE6 */
}

#navlist
{
width: 7em;
/* to display the list horizontaly */
font-family: sans-serif;
margin: 0 0 0 3em;
padding: 0;
border-top: 1px #000 solid;
border-left: 1px #000 solid;
border-right: 1px #000 solid;
}

#navlist a
{
width: 99.99%;
/* extend the sensible area to the maximum with IE5 */
display: block;
background-color: #fff;
border-bottom: 1px #000 solid;
text-align: center;
text-decoration: none;
color: #000;
}

#navlist a:hover { background-color: orange; }
#navlist a:visited { color: #000; }

Easily done. The next thing you have to consider, though, is how your custom menu is going to interact with the other menu users will see when they’re logged in and looking at their account pages.

The User Menu

The user menu is the menu you’ll see on some pages if you’re logged in. The menu links you to your account summary page (your checkouts, overdues, and holds), your fines, user tags, etc. The user menu, when it appears, will appear underneath the menu you added to OpacNav.

After you’ve added a custom menu, log in to your OPAC and see how it looks on the user pages.

It looks fine, but why not take a few extra steps to integrate it better with the look of the existing menu. I’m going to tweak these properties to help match the user menu:

1. border color
2. margin
3. padding
4. width

Here’s the updated CSS:

#navcontainer {
margin-right:0.5em;
padding-top:1em;
}
#navlist li {
display: inline;
/* for IE5 and IE6 */
}

#navlist {
width: 9em;
/* to display the list horizontaly */
font-family: sans-serif;
margin: 0 0 0 1em;
padding: 0;
border-top: 1px #979797 solid;
border-left: 1px #979797 solid;
border-right: 1px #979797 solid;
}

#navlist a {
width: 99.99%;
/* extend the sensible area to the maximum with IE5 */
display: block;
background-color: #fff;
border-bottom: 1px #979797 solid;
text-align: center;
text-decoration: none;
color: #006699;
}

#navlist a:hover { background-color: #D4E2FF; }

That’s the basics. Browse through the Listamatic site for more ideas. And remember, you’re not limited to just navigation links when you’re customizing OpacNav. You can add any kind of static content. The Rockingham Free Public Library lists their hours. The Polytechnic Institute of NYU’s Bern Dibner Library has a Meebo widget for instant chatting between OPAC user and library staff [edit: At least they used to. 7-15-2010].

It’s a narrow canvas, but it’s open for just about anything you can think of.

The Athens County Public Libraries’ OPAC has a display of selections from our “New and Upcoming” book list. Although it is displayed within a Koha page, the content is brought in from an outside Koha. These are the pieces that put it all together:

• A list of new titles, maintained in a separate MySQL database via its own web interface
• A php script to pull out and display a random selection of titles from the list
• Markup for an iframe added to Koha’s opacmainuserblock system preference

Set up the Database

ACPL originally built the infrastructure for maintaining book lists as part of the library’s public web site. The intention was to enable librarians to build any kind of book list. There are two tables, bookshelf and bookshelfitems:

The bookshelfitems table contains the individual items that appear on a list. The sortorder field is not required. ACPL uses it to define a custom sort order for other book lists created for our site.

The bookshelf table contains the names and details of each individual list. This is not strictly necessary if you’re only maintaining one list. The description, bannerimage, category and date-related columns are not required.

In the case of the new book list, a list with shelftitle “New and Upcoming” was created. Then individual items were added to bookshelfitems which specified the shelfid of the “New and Upcoming” list.

Retrieve the Data

The next step is to pull the relevant data from the list for display. Create a new PHP file which does a straightforward query of the database:

<?php
$newtitles_sql = "SELECT * FROM `bookshelfitems` WHERE
shelfid = 1 order by rand() limit 3";
$newtitles_result = mysql_query($newtitles_sql);
?>

Of course your WHERE clause should specify the id of your new book shelf

<table><tr>
<?php while($row = mysql_fetch_array($alllidsresult)){ ?>
<td>
<a target="_parent"
href="http://path/to/koha/opac-detail.pl?biblionumber=
<?php echo $row['biblionumber']; ?>
"><img src="http://images.amazon.com/images/P/<?php echo
$row['isbn']; ?>.01._TZZZZZZZ_PU_PU-5_.jpg" alt="" /></a>
<a target="_parent"
href="http://path/to/koha/opac-detail.pl?biblionumber=
<?php echo $row['biblionumber']; ?>">
<?php echo $row['title']; ?></a>

<?php if($row['authorlast']){ ?>
By <a target="_parent" href="http://path/to/koha/opac-search.pl?q=au:
<?php echo $row['authorlast']; ?>,%20<?php echo $row['authorfirst'];
?>"><?php echo $row['authorfirst']." ".$row['authorlast']; ?></a>.
<?php } ?>
</td>
<?php } ?>
</tr></table>

And of course you should change the URLs to point to your OPAC. As you can see ACPL pulls book cover images from Amazon. That could be modified to point to a different source if your library chooses. When you access your new PHP file directly you should see your titles:

Add to your OPAC

Log in to the Administrative interface of Koha, go to System Preferences, and edit the OpacMainUserBlock preference. This is the essence of the markup that ACPL uses:

<h4>Selections From the New and Upcoming Titles List:</h4>
<iframe src="http://path/to/your/script/upcoming.php" frameborder="0"
style="width: 90%; height: 21em; overflow: hidden;">
</iframe>

Possible Improvements

• iframe height is fixed. The 21 em height of the iframe is a compromise, attempting to set a height that will fit all but the longest titles without creating too much white space. This doesn’t always work.
• Dynamic awareness of overflow in smaller displays. If your browser window is 800 pixels wide or smaller, the third title will be cut off by the overflow:hidden CSS property. A great improvement would be to add Javascript that would check the width of the iframe on page load and remove the last cover completely so that no partial covers were displayed.
• Gracefully handle missing covers. Not every title we list has a corresponding cover image on Amazon.com. There are many techniques available for handling this. The same javascript method Koha uses (adapted from the link article) could probably be applied here.