Customizing the staff client login logo: Addendum

I left something out of my post on Customizing the staff client login logo that I wanted to be sure to add: Once you’ve changed the logo you may want to change where it links to as well. By default it links to the Koha web site (or the deprecated version if your installation is an older one). We can use a little snippet of jQuery to change that link.

Using jQuery to change the URL to which the staff client logo links

$("#login h1 a").attr("href","https://www.myacpl.org");

That looks for an <a> tag inside an <h1> inside <div id="login">, which is specific enough to only catch the login form. This snippet goes inside your intranetuserjs system preference. Assuming the only thing you’ve added to intranetuserjs is the code I covered in the previous post, this would be the revised version:

$(document).ready(function(){
$(“#login h1 a”).attr(“href”,”https://www.myacpl.org”);
});
// ]]>


// <![CDATA[
//

Customizing the staff client login logo

A Koha user (from Tanzania!) asked today on the Koha mailing list, “I need some help on how to customize the staff client login page/replace koha logo with a new one.” I haven’t heard this request before, so it’s a good opportunity to investigate.

If this were the OPAC we could use a system preference, opacsmallimage, to change the logo. We don’t have that option in the staff client, so we’ll have to see if we can use the available customization options to accomplish the same thing.

Our first stop, as usual, is FireBug. I opened up the staff client to examine how the default Koha logo is displayed on the login form. Using the Inspect tool I highlight the logo and view the results in the FireBug HTML inspector window:

FireBug details for the login logo anchor tag

The logo is constructed by nesting a link (“anchor”) tag (<a>) inside a top-level heading tag (<h1>). The above screenshot shows the HTML and style details for the <a>, here are the results for the <h1>:

FireBug details for the login logo heading tag

From this we can collect all the CSS information we need to control the display of the login logo:

#login h1 a {
border-bottom:medium none;
display:block;
height:74px;
text-indent:-1000px;
}

#login h1 {
background:url("../../img/koha-logo.gif") no-repeat scroll center top transparent;
margin-bottom:0.5em;
margin-top:0;
}

The staff client logo is displayed using an image-replacement technique similar to the one used to display the Koha logo in the OPAC. The style of the anchor tag sets an explicit height which matches the logo image, and it sets a negative text-indent property which moves the text contents of the tag off the screen. These two properties create a blank space inside the anchor tag in which to display the logo.

The style of the heading tag does the work of displaying the logo. The background property points to the URL of the logo image. In the default case this is an image file on the Koha server’s file system. The URL doesn’t have to be a relative one, though. It can be a full URL pointing to anywhere on the internet.

Customizing the logo CSS

In order to change the image we need to make very simple changes to two CSS properties:

  1. The background-image of the <h1> tag.
  2. The height of the <a> tag.

Let’s use as an example the logo on the Athens County Public Libraries site. I can right-click the image in Firefox and choose “View image” to find the details I need. The location bar shows the URL I need, and the title bar shows the dimensions of the image. I just need to note the height.

Since we only need to change two properties, our custom CSS is simpler than the original. We only need to specify the properties which we need to override:

#login h1 a {
height:71px;
}

#login h1 {
background:url("https://www.myacpl.org/sites/all/themes/npl/logo.png") no-repeat scroll center top transparent;
}

Applying the custom CSS

We’ve got our custom CSS, now what do we do with it? We don’t have an opacsmallimage preference for the staff client, and we don’t even have an option like OPACUserCSS. We do have a couple of options which will work.

intranetcolorstylesheet

If you have access to your Koha server’s file system you can add a stylesheet there and tell Koha to apply it in addition to the default staff client stylesheet. For example, you could create a new CSS file called custom.css and save it alongside staff-global.css and the other staff client CSS files. Then you can specify that filename, custom.css, in the intranetcolorstylesheet system preference.

intranetuserjs

If you don’t have access to your Koha server’s file system, there’s a way to insert custom CSS into your staff client pages, but it’s a bit of a hack. Lacking an “intranetusercss” preference we’re going to hijack an existing preference, intranetuserjs, to do the job for us.

When you insert custom JavaScript into the intranetuserjs preference, Koha detects this and adds it to the header of each staff client page, wrapped in the appropriate <script> tags:


// 


Since Koha automatically wraps the intranetuserjs content in opening and closing <script> tags, we’ll have to do a little bit of roundabout coding to embed a <style> block:


//


/* Custom styles here */


// 

Let’s run down what’s happening here. Lines 1 and 2 have been inserted automatically by Koha in order to properly embed the custom JavaScript it expects from the intranetuserjs preference. Line 3 is the first line of the contents of intranetuserjs. Lines 4 and 5 we have added manually to close the automatically-embedded <script> tag. With the script tag closed we can go on to add just about any HTML we want, really, but this is all inside the <head> of the HTML document, so few things would be valid.

Lines 6, 7, and 8 show the <style> tag we’re adding. This is where we’re going to put our custom CSS. Lines 9, 10, and 11 are the last lines of our custom intranetuserjs. Knowing that Koha wants to close the <script> tag it opened on line 1, we have to re-open a new <script> tag so that when Koha closes it we’ll have valid markup.

Putting it all together, here’s what the contents of our intranetuserjs preference will be:

// ]]>



/* Custom styles here */
#login h1 a {
height:71px;
}
#login h1 {
background:url("https://www.example.com/images/logo.png") no-repeat scroll center top transparent;
}


// <![CDATA[

If all goes well, this is what you should see when you log out and look at your login screen:

id=”attachment_633″ align=”aligncenter” width=”300″ caption=”Customized login form”

Note: I’ve published a quick addendum to this post which covers using jQuery to change the URL to which the logo links

Interface test: Placing a quick hold

I was thinking about ease of use, and what we could to to improve the Koha OPAC from the point of view of the patrons, and the first thing my mind jumped to was the process of placing holds. For many patrons placing a hold is the goal of their visit to the OPAC. They’re looking for something they want, they find it in the catalog, and they want to get it. On Amazon.com the next step would be to buy it. In the OPAC they can place a hold.

What’s the first thing they see when they click one of those “place hold” links? Potentially this:

Place hold interface with all options turned on

I hate it. It’s an ugly table with too many options. True, you can turn off some of those options for a simpler process. Turn off the OPACItemHolds system preference to eliminate the option of choosing a specific copy. Turn off OPACAllowHoldDateInFuture to hide the Hold Starts on Date column. Turn off OPACDisplayRequestPriority to hide the hold request’s rank in the queue. Now it’s a little simpler:

With optional settings turned off

I’m still not crazy about it, and that’s why holds came to mind when I thought about what we could do to improve interactions in Koha. How can we make that interaction simpler? How about [almost] one-click “ordering?”

Click the "Place hold" link in the right sidebar

When you click the “Place hold” link you can see my idea demonstrated. Clicking the link would use JavaScript to display a simple form: Place hold? Yes/No. Embedded in the HTML would be all the required form fields, hidden, for placing a single hold with no options set, using the patron’s home library as the destination for the hold. If the patron wanted to set additional options they could click the “more options” link and be taken to the standard form.

How hard would this be to implement? It depends how far you want to take it. I could seeĀ  this being a JavaScript-only enhancement, assuming all the information we need is found on this page. In this version clicking the “Yes” button would submit the form to the same script the standard form does, but bypass the hold confirmation screen. The user would be redirected to their summary page showing current holds.

A fancier version would submit the form in the background. Clicking the “Yes” button would triggers a sequence of events:

  1. The hold would be submitted in the background.
  2. The interface would display some kind of “Working” indicator.
  3. Upon completion of the background submission, the interface would indicate success.

This is more complicated because the reserve script would have to be modified to work in new way. Error-handling would have to be incorporated so that if for some reason the hold couldn’t be processed the user could be warned. The advantage to this interaction is that the user never leaves the page, making it easier for them to find their way back to their original search–something which, incidentally, is also on our to-do list of ways to make things easier for the user.

Koha bugs workflow

As the Koha project has grown our workflow has evolved to meet the demands of a wider pool of developers. We’re better today at collaborating thanks to Git, our version control system. We’re better at communicating with each other through the Koha wiki and Koha’s Bugzilla database. It has helped a lot that we’ve worked to establish some consistent steps to handle both bugs and new features.

Filing a bug report

When you’ve discovered a bug in Koha the first stop is Bugzilla. Bugzilla is an open-source bug-tracking system developed by the folks who brought you Mozilla Firefox. We have our own installation of Bugzilla, generously hosted on a donated server. Anyone can file a bug, whether you’re a Koha developer or a Koha user.

If you find a bug the first step is to report it. Even a developer intending to immediately fix a bug should file a bug report. Doing so will mean others won’t duplicate your efforts in isolating the bug. When you file a bug report Bugzilla will offer to assign the bug by default to the person who has volunteered for bugs of that category. For instance, I am assigned by default any OPAC bugs. That doesn’t mean I’ll be able to fix them all, but I’m notified of each one and I can always reassign them if I find they’re beyond my capabilities.

You can also assign the bug a “severity” setting. If you’re not sure, use the “normal” severity for bugs, and “enhancement” if you’re asking for a feature to be added. There are brief descriptions of Bugzilla’s severity levels for review if you’re not sure how to classify something.

There are much more detailed bug reporting guidelines on the Koha Wiki.

Now the bug is in the database. With any luck, anyone else who discovers the same bug will search Bugzilla first before reporting it. If you find an existing report for a bug you’re experiencing, review it to make sure all the pertinent details are there. Feel free to leave comments expressing in specific terms how the bug is affecting your library’s workflow. Understanding the impact of a bug might help others prioritize efforts to fix it.

What happens to your bug?

What happens to a bug report after it gets filed? If the report was filed without any plans to address it (that is, if you’re not a developer filing the bug, with plans to fix it right away), nothing may happen for a while. Ideally the default assignee of the bug will review it and take some action if necessary: Correcting the bug’s severity, asking clarifying questions, reassigning if necessary. Unfortunately there is no guarantee that anything will happen with a bug report once it is filed. If no one else is affected by (or cares about) the bug, there won’t be any incentive to fix it. Developers are often working on projects assigned to them by their customers, and if they’re not getting paid to fix a particular bug they may not choose to work on it.

Your bug finds acceptance

If someone decides to work on your bug report, the first thing they should do is “accept” the bug in Bugzilla. If the bug isn’t already assigned to them, they edit the bug to assign it to themselves and update the status of the bug from “New,” the default for all new bugs, to “Assigned.” This tells anyone browsing Bugzilla that someone has agreed to work on the bug. Careful use of bug assignment and the use of the “assigned” status helps prevent duplication of effort: I won’t spend time working on a bug if I think someone else is actively working on it already.

If the developer who took on your bug discovers a fix for it, the next step is to submit a patch. A patch is a special file which can be understood by our version control system. Just as a patch on a piece of clothing is just a small piece of cloth to fix a hole, a software patch is just a small piece of code which can be applied to a whole file (or even multiple files). The patch includes instructions to add certain lines or remove certain lines of code.

The developer who has come up with a patch will do two things with it: First, the patch gets submitted to a special Koha mailing list for all Koha patches. Koha’s Release Manager monitors this list and evaluates each patch and evaluates it for inclusion in the next version of Koha. The second place the patch will go is into the Bugzilla bug report. The developer will attach the patch to the bug report so that others can see that a patch was submitted and maybe review the patch themselves. Since the patch file is easily understood by the Git version control system, anyone running an installation of Koha from a Git repository can apply patches and test bug fixes. A bug in Bugzilla which has has a patch filed for it will be marked with a special priority, “PATCH-sent.”

Your bug found acceptance, but what about the patch?

Galen Charlton, the Koha 3.2 Release Manager, has the task of evaluating each patch that is submitted for inclusion in 3.2. He reviews patches, tests them, and approves them if he finds them worthwhile. If a patch refers to a specific bug report, Galen will usually also update the bug report with a note that the patch was “pushed.” If a patch doesn’t seem to work, or if it includes mistakes which should be corrected before inclusion he will let the patch submitter know so they can rework the patch.

Right now we’re getting so close to the release of 3.2 that we’re under both a “feature freeze” and a “string freeze.” A feature freeze means that no new features are being accepted for inclusion in 3.2: only bug-fixes. Rejecting new features at this point in the process reduces the possibility that major new bugs will be introduced. The “string freeze” means that patches submitted for inclusion in 3.2 should no include changes to any text in the interface. These text strings must be painstakingly translated. The Koha translation-tracking system Pootle lists 63 different languages which have at least begun to have translations done. Putting on a string freeze means that translators preparing for the release of 3.2 will have a fixed target.

The patch for your bug made the cut. It’s going into 3.2!

You reported the bug, so your job isn’t done yet. It’s time to test the fix. Update your test installation and try to follow the same steps that led to the bug before. Is the bug still there, or is something still left undone? Then update the bug and explain what you found.

On the other hand, if you find the bug has been fixed then you can mark it as such in Bugzilla. Change the status of the bug from “Assigned” to “Resolved (Fixed).”

Congratulations, and welcome to the team.

Nearing Koha 3.2

It has been six months since my Preparing for Koha 3.2 post! It’s been a while, but a lot of progress has been made. If my Bugzilla query is correct, we’ve resolved almost 200 bug reports in that time. Over 1000 commits have been made to Koha’s code repository for version 3.2. We’ve released two Alphas and a Beta. As of today we still have some “blocker” bugs, meaning bugs which are so severe that they must be fixed before an official release.

Yesterday we had one of our monthly Koha General Meetings on the #koha IRC channel and our 3.2 Release Manager Galen Charlton stuck his neck out and made this promise: “In no event will general release happen later than the general meeting next month.”

Let the final sprint begin!