Tag Archives: Koha

A quick Firebug tip for editing CSS

I’ve talked before about Firebug’s inspector tool for examinating the markup of a page and its associated style. When you inspect a particular element in the markup you can see the CSS rules that have been applied to it. But what if the styles applied to an element change based on user interaction? How do you “catch” the style of a hover interaction, or of an element which has focus?

For instance: In the Koha staff client there is a global style for the color of a link when you hover your cursor over it.

Koha link color on hover

This color is defined in the staff client’s main CSS file, staff-global.css:

a:hover, a:active {
color : #538200;
text-decoration: none;

However, if you use Firebug’s inspector to examine a link you won’t see that CSS:

Inspecting a link in the staff client

That’s because the Firebug inspector isn’t showing you the “hover” state of the link–at least not unless you’re mouse cursor is hovering over the link at the time:

Inspecting the link on hover

But what if we want to use Firebug’s Style tab to live-edit the CSS of the hover state? As soon as we move our mouse away from the link the hover state disappears from the style pane, so we can’t edit it. Luckily Firebug has an option built in for “activating” three different interaction states: Hover, Active, and Focus:

Firebug Style tab interaction options

By selecting “:hover” we can “pin” the hover state to keep it activated so that we can inspect and change it:

Edit the hover style in Firebug

We can test the “focus” option by inspecting the style of any standard text input in Koha, for example the barcode field on the check-in page:

Inspecting an element's :focus state in Firebug

This lets us see that there is a CSS rule defining a default border style for <input> and <textarea>

input:focus, textarea:focus {
border-color: #538200;
border-radius: 4px;
border-style: solid;

And from there we can customize away:

input:focus {
border-top: 5px solid #EF5959;
border-bottom: 5px solid #FF975F;
background-image: -webkit-gradient(linear, 0 0, 0 100%, from(#EF5959), to(#FF975F));
background-image: -webkit-linear-gradient(#EF5959, #FF975F);
background-image: -moz-linear-gradient(#EF5959, #FF975F),
-moz-linear-gradient(#EF5959, #FF975F);
background-image: -o-linear-gradient(#EF5959, #FF975F),
-o-linear-gradient(#EF5959, #FF975F);
background-image: linear-gradient(#EF5959, #FF975F),
linear-gradient(#EF5959, #FF975F);
-moz-background-size:5px 100%;
background-size:5px 100%;
background-position:0 0, 100% 0;
border-width: 5px 0;
padding: 5px;

A custom input border

Customizing the display of online resources like eBooks

The Athens County Public Libraries are members of the Ohio eBook Project Ohio Digital Library, a consortium of libraries who contribute to and share access to a collection of eBooks and other downloadable material through OverDrive. In order to make these resources more discoverable by our patrons we add MARC records for these titles to Koha.

When we started doing this we felt that it was important for the patrons to be able to tell very easily that the title they saw in search results was an electronic resource they could download. We already have many records in our catalog for web sites. We were concerned that these two types of resources would be difficult to distinguish.

Electronic resource in search results

An electronic resource in default OPAC search results

Since Koha gives us the ability to inject custom JavaScript into our OPAC, a JS-based solution seemed like the best option. The goal was to be able to use JS to examine each search result and look for a clue that any particular result was an Ohio eBook Project record. Luckily all the OEP records have something in common: A URL (stored in the MARC 856u) beginning with “http://ohdbks.” Here’s the JavaScript I came up with:

$("#userresults table td").each(function(i){
td = $(this);
var ohdbks_link = td.find("a[href^='http://ohdbks']");
var linkc = ohdbks_link.parent();
var ohdbks_link = ohdbks_link.attr("href");
$("td:eq("+i+") span.availability,td:eq("+i+") span.actions").hide();
linkc.html('<a class="ebook" href="'+ohdbks_link+'">Check the Ohio e-Book Project for availability</a>');

Stepping through this code:

  1. The script is triggered when #userresults is ready.
  2. We loop through each td within the table inside #userresults, storing the index of each iteration as i.
  3. The matched td is stored as a variable for easy reference.
  4. The script finds an anchor tag which matches the string we’re looking for and stores that in a variable.
  5. We want to refer later to the <a> tag’s parent container, so we use jQuery’s parent() to store that as linkc.
  6. We pull the href attribute value for the previously select <a> tag.
  7. If an href was found…
  8. …hide the availability and “actions” (“Place hold,” “Add to cart”, etc.) elements which we don’t consider relevant to e-resource records.
  9. Replace the contents of the original anchor tag’s container with new html which uses the previously-saved href attribute but changes the text of the link and adds a special CSS class.

We chose to label each eBook link “Check the Ohio Digital Library for availability” because Koha has no way of knowing whether a particular title is checked out. The link is styled by CSS added to Koha’s OPACUserCSS system preference:

a.ebook {
background: url("https://www.myacpl.org/files/image/opac-results-download-ebook.png") no-repeat scroll 5px 5px transparent;
border: 1px solid #8BC45C;
border-radius: 5px 5px 5px 5px;
font-size: 135%;
font-weight: bold;
line-height: 175%;
padding: 4px 4px 4px 25px;
text-decoration: none;

The result:

Electronic resource in customized search results

An electronic resource in customized OPAC search results

Electronic resource detail page

When the patron clicks to view more information about one of those electronic resource titles they come to a detail page which presents additional opportunities to simplify the display for this type of record.

Since this kind of title is available only through the Ohio Digital Library web site we don’t actually have any local holdings, but when we add MARC records for these resources we include a dummy item to which we can attach some additional information. One reason for this is to be able to have a searchable collection code attached to each record. But showing holdings information to the patron isn’t very useful because none of it is relevant:

Holdings information displayed by default for electronic resources

Holdings information displayed by default for electronic resources

Another aspect of the detail page which is less than ideal is that the link to the Ohio Digital Library is pretty well hidden in the other details about the title like publisher, subject headings, etc. We again turned to JavaScript to solve both of these problems at once:

var ohdbks_link = $("span.online_resources a[href^='http://ohdbks']").attr("href");
$("#holdings").html('<a href="'+ohdbks_link+'"><img src="https://www.myacpl.org/files/image/opac-download-ebook.png" alt="Check the Ohio e-Book Project for availability" /></a>');

This code is very similar to what we used on the search results page, but a little simpler.

  1. Again we trigger this function when this particular area of the page (“span.online_resources”) has completed loading.
  2. We find the link to the Ohio eBook Project download page and store the href attribute.
  3. If an href was found…
  4. Replace the holdings table (identified by the ID #holdings) with an image which links to the OEP download page.

In four lines of JavaScript both goals are accomplished: The meaningless holdings table is gone, and a prominent link is added to the Ohio eBook Project download page for the title the patron is looking at.

Here’s the result:

A customized link to the electronic resource download page

A customized link to the electronic resource download page

Cart and Lists buttons revisited

It’s been almost three years since I wrote Colorizing the Cart and Lists buttons. My conclusion then was that we needed a fairly complex combination of markup, CSS, and background images to create the appearance of the buttons.

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.

The time has come for the simpler version. My patch for Koha bug 7584, “Update cart and lists buttons style using CSS3 features” has just appeared in Koha’s master branch, the development version which precedes an official release.

What has changed? Firefox, Safari, and Chrome have had updates since then, which has at the very least expanded the number of users of those browsers who are on a more recent version. Opera, one of the holdbacks in 2009, now supports the features required. Internet Explorer 6, 7, and 8 still linger of course, but Internet Explorer 9 is available now. IE9 offers better support for the features we need.

For me what has changed is that I now think that Koha should be a little more aggressive about taking advantage of the features of up to date browsers even if that means the experience isn’t the same for users of older browsers.

The new style

Let’s take a look at the revised markup. Where the previous version needed a lot of extra elements (<i>, <span>, etc) the new version doesn’t:

<a href="#">Cart</a>

<a id="listsmenulink" href="#">Lists</a>

I’ll quote the relevant declarations from the CSS. First, both buttons are assigned rounded corners:

#cartmenulink, #listsmenulink {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;

Notice the variations: “-webkit-border-radius” is specific to Chrome and Safari. “-moz-border-radius” is specific to Mozilla-based browsers like Firefox. When we specify a single value like “5px” the value is applied equally to all four corners. You can also specify different values:

#cartmenulink, #listsmenulink {
-webkit-border-radius: 4px 15px 4px 15px;
-moz-border-radius: 4px 15px 4px 15px;
border-radius: 4px 15px 4px 15px;

The values are applied clockwise starting with the upper left-hand corner.

Background Gradients

The other primary aspect of the buttons are their background colors. Previously we used a transparent image to give the button background a gradient. With CSS3 we can specify the gradient values right in our CSS. The easiest way to accomplish this is using the Ultimate CSS Gradient Generator.

A web-based tool for designing CSS gradients

With the CSS Gradient Generator you can use the visual tools for creating a gradient and the CSS will be generated for you. It generates CSS declarations specific to several major browser versions including Internet Explorer. There is even an option to upload a gradient image and have the Generator automatically match the colors.

Here’s the gradient CSS for the Cart button:

#cartmenulink {
background: #98CB58; /* Old browsers */
background: url("../../images/cart.gif"),-moz-linear-gradient(top, #d5eaba 0%, #b7db8a 50%, #98cb59 100%); /* FF3.6+ */
background: url("../../images/cart.gif"),-webkit-gradient(linear, left top, left bottom, color-stop(0%,#d5eaba), color-stop(50%,#b7db8a), color-stop(100%,#98cb59)); /* Chrome,Safari4+ */
background: url("../../images/cart.gif"),-webkit-linear-gradient(top, #d5eaba 0%,#b7db8a 50%,#98cb59 100%); /* Chrome10+,Safari5.1+ */
background: url("../../images/cart.gif"),-o-linear-gradient(top, #d5eaba 0%,#b7db8a 50%,#98cb59 100%); /* Opera 11.10+ */
background: url("../../images/cart.gif"),-ms-linear-gradient(top, #d5eaba 0%,#b7db8a 50%,#98cb59 100%); /* IE10+ */
background: url("../../images/cart.gif"),linear-gradient(top, #d5eaba 0%,#b7db8a 50%,#98cb59 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#d5eaba', endColorstr='#98cb59',GradientType=0 ); /* IE6-9 */


Eight lines of CSS each doing the same thing for different browsers, starting with a solid background color for browsers which don’t support CSS3. This is the same kind of code which will be generated by the CSS Gradient Generator with one exception: The OPAC CSS also includes a background image for the Cart button in order to display the little cart icon.

There’s more to the styling of the buttons than rounded corners and background-gradients, but nothing which we haven’t seen before. Fire up Firebug (or your favorite browser’s DOM inspection tool) and inspect the buttons for more information.

What have we gained?

Just looking at the HTML markup it would seem we’ve gained a lot of efficiency over the <span>-heavy buttons in the older version. But the multiple lines of CSS more than make up for it. What advantages does the new design offer? Importantly, flexibility. We don’t have to create custom-colored 24-bit transparent images when changing the background color of the search bar. We can make all our changes, including changes to the Cart icon, right in the CSS. Border color, border radius, background-color (or gradient), it’s now 100% CSS and can be affected by a custom stylesheet or by changes to the OPACUserCSS system preference.

This change is going to require some revisions if your library has existing CSS customizations to these areas of the OPAC, but I think going forward these changes are going to prove to be beneficial to those seeking to customize their OPAC’s appearance.

Proposed feature: A recent comments view in the OPAC

Koha’s OPAC has a feature which lets logged-in users leave comments about records in your catalog. This feature was originally branded as “Reviews,” but was changed to “Comments” in order to align it with the familiar feature allowing users to comment on content in blogs, on YouTube, etc. If you haven’t seen it before, here’s what it looks like to a logged-in user:

A catalog record with comments

If you visit the Athens County Public Library catalog you’ll find that comments are enabled, but few users have taken advantage of the feature. I’ve often wondered what we could do to encourage people to add their comments, and one of the ideas I had was to feature recent comments–perhaps on the OPAC or library web site home page.

I’m not an experienced Perl programmer. Most of the changes I make to Koha’s Perl code are minor or cut-and-paste. Adding a feature as unformed as a recent comments view was a little daunting, but I think it turned out well, and I hope I did it right! I’m quite pleased with the result:

Recent comments

The page shows the latest comments added to any title in the catalog in descending order by date. The page also offers an RSS feed of recent comments. This offers two benefits: First, patron can subscribe to recent comments if they want to find out what others are talking about; and second, the library can use that feed to pull content into their own web site. If my library site’s content management system can process an RSS feed, I can add those recent comments on my library’s web site too.

Of course it’s too late in the development cycle for this feature to make it into 3.2, but I hope it will arrive with 3.4.

A collaborative process

There’s one more thing I wanted to share about the development of this little feature: When I was creating the RSS feed I was testing it with the W3C’s feed validator to make sure I had constructed the markup for the feed correctly. The only error I didn’t know how to fix was one with date-formatting. The validator told me I needed to  format my date according to RFC 822, but Koha didn’t include a way to format dates that way. I put out a plea on the Koha IRC channel which was answered by Chris Nighswonger. He very generously added the code I needed and I was able to include a valid RSS feed.

This anecdote shows the very best kind of interaction possible when you work with an open community of developers. I’m not suggesting that in the Koha world all one has to do is ask and free code will be provided. But sometimes you catch someone at the right moment, or the challenge appeals to them, and they pitch in. Many thanks to Chris for doing so when I needed help.

Showing item type counts on the checkout screen

Does your library limit your patrons to a certain number of checkouts for certain item types? At the Athens County Public Libraries, for instance, we limit patrons to 10 audio books, 10 music CDs, 10 videos, and 5 DVDs at a time. If a patron tries to check out more than 5 DVDs, Koha will show a warning. But what if you want to be able to tell at a glance how many a patron has?

This functionality was available to us in our 2.x installation, but when we upgraded to 3.0 our support company at the time told us it wasn’t a customization they would support. This wasn’t a feature we were willing to give up, so I set out to duplicate it using the tools available to me: system preferences and JavaScript.

Information there for the taking

All the information we need can be found on the patron checkout screen, we just need to figure out how to get it. The page lists all the items checked out to the patron, and it shows the item type for each:

List of items checked out on the checkout screen

With this available to us we can use jQuery to count each instance of each item type. We need to build a count for each item type in our system, so the script isn’t very portable. It looks for table cells (“<td>“) containing the description of each of our item types:

var itypes = {'circ': 0, 'avid': 0, 'avbk': 0, 'avmu': 0, 'advd':0 };
$("#issuest td:contains('Circulating')").each(function(){
$("#issuest td:contains('Videos')").each(function(){
$("#issuest td:contains('DVDs')").each(function(){
$("#issuest td:contains('Audio Books')").each(function(){
$("#issuest td:contains('Music CDs')").each(function(){

The script starts by setting up an array of all my item types (“circ,” “avid,” etc.) and giving each a value of zero. Then the script looks for instances of each item type description on the page,  “Circulating,” “Videos,” etc., using jQuery’s :contains selector. Each time it finds an instance of one of those text strings the script increments the count for that item type. At the end of the process the script will have the count for each item type.

Displaying the counts on the page

In order to show the item type counts on the page we need to lay some groundwork by adding some markup. I want to add the count information right after the “Checking out to…” heading, so I’ll find that element’s ID using FireBug and jQuery’s after() function:

$("#circ_circulation_issue label[for='barcode']").after( ... );

The HTML I’m going to add is the default state, so it shows a zero count for everything:

<p style="margin-top:1em">
<span id="avmuout">0</span> Music CDs out, <span id="avmuok">10</span> More Allowed
<span id="avbkout">0</span> Audio Books out, <span id="avbkok">10</span> More Allowed
<span id="avidout">0</span> Videos out, <span id="avidok">10</span> More Allowed
<p style="margin-bottom:1em">
<span id="advdout">0</span> DVDs out, <span id="advdok">5</span> More Allowed

I’ve  included unique IDs for the “count” spans so that I can easily update them with my script:


$("#avidok").html( 10 - itypes["avid"] );
$("#advdok").html( 5 - itypes["advd"] );
$("#avbkok").html( 10 - itypes["avbk"] );
$("#avmuok").html( 10 - itypes["avmu"] );

In the first of the two sections above I take the count I got earlier, itypes['avid'] and set the content of the corresponding <span> using the html() function. I also want to show how many more the patron can check out, so I subtract the count from the limits I’ve set in my Koha installation.

If you have patrons who have exceeded their checkout limit you’ll see a problem: The page will tell you they’re allowed to check out a negative number more items. We can correct the script to accommodate:

$("#avidok").html((10-itypes["avid"] &gt; 0) ? 10-itypes["avid"] : 0);
$("#advdok").html((5-itypes["advd"] &gt; 0) ? 5-itypes["advd"] : 0);
$("#avbkok").html((10-itypes["avbk"] &gt; 0) ? 10-itypes["avbk"] : 0);
$("#avmuok").html((10-itypes["avmu"] &gt; 0) ? 10-itypes["avmu"] : 0);

Final version

Here’s what the results look like:

The final version includes proper escaping of the HTML content and wraps the whole process into a function (“itemTypeCount”). This function will be called on page load only if jQuery finds that the table of checkouts, which has an ID “issuest” is being displayed. The whole script goes into Koha’s intranetuserjs system preference.

function itemTypeCount(){
$("#circ_circulation_issue label[for='barcode']").after("<p style="margin-top:1em" class="icount"><span id="avmuout">0</span> Music CDs out, <span id="avmuok">10</span> More Allowed</p> <p class="icount"><span id="avbkout">0</span> Audio Books out, <span id="avbkok">10</span> More Allowed</p> <p class="icount"><span id="avidout">0</span> Videos out, <span id="avidok">10</span> More Allowed</p> <p style="margin-bottom:1em" class="icount"><span id="advdout">0</span> DVDs out, <span id="advdok">5</span> More Allowed</p>");

var itypes = {'circ': 0, 'avid': 0, 'avbk': 0, 'avmu': 0, 'advd':0 };
$("#issuest td:contains('Circulating')").each(function(){
$("#issuest td:contains('Videos')").each(function(){
$("#issuest td:contains('DVD')").each(function(){
$("#issuest td:contains('Audio Books')").each(function(){
$("#issuest td:contains('Music CDs')").each(function(){
$("#avidok").html((10-itypes["avid"] &gt; 0) ? 10-itypes["avid"] : 0);
$("#advdok").html((5-itypes["advd"] &gt; 0) ? 5-itypes["advd"] : 0);
$("#avbkok").html((10-itypes["avbk"] &gt; 0) ? 10-itypes["avbk"] : 0);
$("#avmuok").html((10-itypes["avmu"] &gt; 0) ? 10-itypes["avmu"] : 0);


This system works very well for my library, but it comes with a few caveats:

It requires that you hard-code, in the script, handling for each of your Koha item types.

Besides being tedious, it also requires that you modify the script each time you change your item types.

It requires that you hard-code the correct item type limits.

Also tedious, and requires that you modify the script each time you change your circulation rules.

It creates a potential collision with both call numbers and titles.

If my item type description is “DVD” and my call number includes the text “DVD” as well I’ll get an inaccurate count. If my item type description is “Audio Books” and a patron has checked out a print book entitled Audio Books for long trips I’ll get an inaccurate count.

For us the disadvantages are not unwieldy and the collision problem has never caused a problem. The advantage we get is being able to tell at a glance whether the patron is going to be able to check out that stack of DVDs or whether we need to ask them to put some back. Better to ask them to pick their favorites up front rather than after we’ve already checked out some of them.