VuFind Orientation

This post will try to be a brief guide to getting a feel for administrating a VuFind installation.

It’s not a definitive account, just my own experience so far. I’m still learning.


VuFind uses Apache Solr to index records and provide such things as facets. Some have described Vufind as a lite frontend to Solr, but I feel this is a little unfair, a car is more than an engine, and VuFind does more than just return search results.

VuFind is PHP based, making use of various PEAR libraries and uses MySQL for various settings. Solr is written in Java and will essentially run a web server on a different port which VuFind will use to query it. VuFind uses Smarty for templates.

The VuFind installer takes care of all of this, but at times you may find it needs a little tweaking (when I used it a few months a go it wasn’t downloading/installing Smarty correctly.

So in all, VuFind requires a based LAMP stack (Linux , Apache, MySQL, PHP), PEAR, Java (Tomcat), Solr, and Smarty. Other OS can be used with a little extra work.

I’ve also created an install script which works on Fedora based systems (I tested it on the Amazon AWS Linux installation which is based on Fedora). The difference with my script is that it will allow you to install multiple instances of VuFind on to the same server with ease. It uses an instance name which is used for the installation directory, url, database name etc, it also uses a different port number for the Solr server for the instance. Even if you don’t use the script I recommend you look at it to get a feel of what it is doing.

The installation notes for the CReDAUL project can be found here.

Useful urls

Vufind comes with an administration site.

This provides a way to view some statistics, some configuration (including ability to edit), and internal Record view. the htpasswd file is located in services/Admin directory, you can add a user to gain entry to the admin site. Also change the password on the default admin user, and consider restricting to local IP addresses.

You can also view the solr index on the port number it is running on e.g.


The top level of the vufind directory (by default /usr/local/vufind/ ) is of use for (a) starting/stopping vufind (b) importing records.

I should say here, when we talk about starting/stopping VuFind (using we are really talking about starting/stopping the Solr service (Vufind wont do anything without it).

You will spend 90% of your time administrating VuFind within the ‘web’ directory, but before will move on to that we’ll mention the ‘solr’ directory.

solr – you’ll never guess – contains the solr installation. Including relevant logs and configuration. A useful file is solr/jetty/etc/jetty.xml which contains the configuration, including such things as port number and the number of threads to run. The actual index is stored in solr/biblio/index – if you’ve got a problem with your records, just delete the directory and re-import your MARC files.

Just before we move on to the ‘web’ directory I’ll mention the import directory, if contains the config for the import script which may need some tweaking.

The web directory.

These are the main sub-directories of the web directory:

  • conf – the first file you will probably play with is the config.ini within this directory. It contains a lot of settings, from the core (what URL does it use), to quite specific settings and options. You’ll also find here the configuration file for the driver which is used to connected to your ILS (aka LMS), and a few more to configure facets (which ones are shown in which order) and searches.
  • Drivers – the driver file which connects to your ILS is found here. Depending on what system you use you may find it needs tweaking to meet your needs.
  • interface – you’ll find the smarty templates in interface/themes – more on this below
  • lang – language files. Useful to define local terms, in your library do you refer to a Lending Desk, Issue desk, Service Point or Circulation desk? Vufind makes it easy to set this, for us in the English speaking world in the en.ini file, in fact this is much neater than many commercial products.
  • RecordDrivers – two key files IndexRecord and MarcRecord.php. The latter is a child/extension of the former. IndexRecord contains methods for exposing record details (for use in smarty templates) for any sort of bib record. MarcRecord extends this with MARC specific information.
  • services – key php application files. I haven’t found the need to edit anything in here yet, but can help to understand how system is structured.


I quite like how Smarty is used, it keeps the interface quite separate from the rest of the logic and code. Though I have heard others say that it is essentially a templating system (with it’s own code and syntax) built on top of a language that in many ways was designed to be just that (PHP).
Vufind has a number of out-the-box themes, by default it uses the one called, well, default. And also mobile if it detects the user is on a mobile device.
I wont describe everything here, you can often guess which file is used for what on screen, it may take a couple of guesses but it is normally quite quick to see if this contains the html code you are interested in changing once you have opened the file.
At the top level there is layout.tpl, and footer.tpl which contain system wide layout templates. There’s also a css and a images file (there’s also a images dir higher up for images which are not theme specific).
  • The homepage is in Web/home.tpl
  • Record and Search dirs have contained most of the files I’ve needed to edit
  • You can see many Smarty tags within the files to translate terms in to the local language and local terminology. for example {translate text=”Add to favorites”} which insert what text you have chosen for ‘adding to favorites’, e.g. ‘Add to My List’ etc.
  • The Record files use variables created in the IndexRecord/MarcRecord files (see above ‘RecordDrivers’). So you can refer to those files to see which variables will contain the information you want to show. Different information is exposed to different views, e.g. the export citation option has just the information required to create a citation. If you want to add an extra bit of information to a citation then you will need to probably edit the RecordDriver files to make sure they expose the data, and then edit the appropriate smarty template file to incorporate it.

Some examples of changes

  • For internet resources we use the MARC 856 field, subfield $u contains the actual link and subfield $y contains the text to use for the link. However vufind presumes the link text will be in subfield $z (which we don’t use) so out the box it would use the URL itself as the text for the link as we had no z. To fix this we edited RecordDrivers/MarcRecord.php so that the getURLs function uses the y subfield.
  • Our setup actually searches two libraries, those of the University of Sussex and University of Brighton. We pre-process the MARC records from each University to add a 969 field for each University which has the item in question. The 969 contains the University code (susx/brighton), and the bibid the library uses for the item (if both Libraries have the item then the record has two 969 fields). When we display a record we want the user to be able to easy link to the record in the main catalogue of the University in question. To do this we edited MarcRecord to create a function which can take this MARC field and turn it in to a link (using the bibid to create a link to the catalogue record in question). I think we also created a skelton function in IndexRecord (which the function in MarcRecord over rides). Finally we edited interface/themes/default/RecordDrivers/Index/core.tpl to add the field to the default record display. [to see the MARC tags referred to here and the example above see this record ]
  • We didn’t want the search results to show availability/shelfmark. With two library systems there was too much potential for mistakes to creep in, best left to the record view of the item. Plus it meant VuFind had to get information for every item on the search results page, potentially putting a load on the original ILS (LMS) server(s). This is actually something which uses AJAX. And this is something which uses the design where a MARC record extends what a ‘default’ record can do (i.e MarcRecord.php extends IndexRecord.php in RecordDrivers). VuFind decides that if something is a MARC record it has come from a Library system and so it can try and find holdings/availability. Essentially the IndexRecord function getSearchResult() will set $interface->assign(‘summAjaxStatus’, false); so it wont try and get availability via AJAX. Where as MarcRecord overrides the function, doing all but the same with everything else but sets that value to true. The smarty template for search results (interface/themes/default/RecordDrivers/Index/result.tpl) then uses the value of summAjaxStatus in a if statement, if true it will output some html/javascript code to perform thee AJAX calcode to call and display the results. So, to do what we wanted, we changed MarcRecord to set summAjaxStatus to false (so it should always be false). And then edited the smarty file so that what gets shown when it is false meets our needs.
  • We edited the help files in interface/themes/default/Help/
  • we changed the order of facets in conf/facets.ini
  • We edited interface/themes/default/Record/view-holdings.tpl so that it doesn’t show ‘item 1’, ‘item 2’ etc next to each copy of the item (we found the numbers weren’t really helpful and didn’t mean anything).
  • And much more….
These examples show that it is quite easy to customise vufind, once you know which files to poke around in.
I can say that the only other system which compares in this flexibility, in my experience, is Eprints. I have not come across a single commercial system (catalogue or otherwise) which we use as a library which has such a structured and logical design.


This project is partly being funded by the JISC as part of their Library Management Systems Programme (referred to as jisclms). The JISC provide services and fund projects related to developing University IT, Libraries, web services, e-learning and research.

The various projects (all based at UK Universities) which are being funded by jisclms recently met up in Glasgow for a two day meeting. This was a incredibly productive event, to discover what others are working on,  share experiences and , and discuss areas and issues which we currently face with library management systems. The latter included issues around OSS LMS (what are the issues, and how could they see the introduction in UK academic libraries), Shared Electronic Resource Management and Usability/User Experience.  What was clear was that the benefit of the projects as whole was greater than the sum of each project combined. Each project requires that University to reuse, open up, or export data in a new way. It forces openness and the net effect is that there will be multiple people around the UK who have recent experience in using LMS data and using it with new applications. This helps create a community who and share and promote such innovation, and help others who are interested in trying such things. It helps to set a ball rolling, or rather, gives a ball which was starting to move slowly a very big push.

Elevator Pitch

  • The name “elevator pitch” reflects the idea that it should be possible to deliver an elevator pitch in the time span of an elevator ride, or approximately thirty seconds to two minutes.‘ (wikipedia)
  • Militant British-English speakers may prefer “lift pitch”
  • Those who find a ‘pitch’ a little crass may prefer ‘concise-explanation-of-product-or-idea-while-in-lift’. Frankly, it looses some bite.
  • Here’s ours…

The University of Sussex and The University of Brighton have various partnerships and joint initiatives, helped by their close proximity. The most prominent of these is the joint medical school: BSMS (Brighton and Sussex Medical School).

The CReDAUL project is creating a combined web catalogue of the University of Brighton and the University of Sussex Libraries. It will contain all the items of both libraries in one interface, so users can see at a glance if either library has a book or other item, and if so at which library and branch.

What’s in it for Sussex? Researchers and students can easily search University libraries to see if a book is available locally. Library staff trying to locate an item for a user will find it useful, e.g. to check for Interlibrary loan requests, increasing efficiency and service. Users have another interface to search the Sussex catalogue should our main catalogue not be available, you can restrict a search to just one Library. It helps us to work together with Brighton in developing something, and the end product may help future collaborations. The interface will are developing (called VuFind, a free off the shelve application used by other Universities) has good support for mobile devices and integrating with applications such as Zotero.

What’s in it for BSMS? At the moment they have to search two different catalogues as their books and resources are split between the two Universities. They will now just need to do one search and can quickly see which Library it is at and if it is available. This will improve the experience for the medical students and staff, who often have a very high work load.

What’s in it for the local community? members of the public may have reason to refer to an item in a local academic library. If they wish to access an academic book, and would like to check to see if it is in a local academic library, they can now do so using just one search from one interface.

What’s in it for other Universities? We are writing up our experience on this blog, and finding other ways to share what we have learnt. Using Open Source discovery layer applications is something of a hot topic at the moment. We have looked at two: Vufind and Blacklight, and are writing up our findings. We are also writing up our experience with VuFind and how we installed it. We’ll also write up how we found setting up a union catalogue of two libraries records and holdings.

PS some background to this post:

What’s CReDAUL

JISC logo


This is the project blog for the JISC CReDAUL project. CReDAUL stands for “Combing Resource Discovery Across University Libraries”.

In a nutshell: We are going to select an Open Source Resource Discovery web application, choosing between either Blacklight or VuFind, and set it up to contain the library catalogue records of both the University of Sussex and the University of Brighton. Its primary users will be the medical school.


Brighton and Sussex Medical School (BSMS) is a joint venture between the University of Sussex and the University of Brighton and admitted its first cohort of undergraduates in 2003. Students and staff of the School have full access to the facilities and resources, including the libraries, of each university.

Medical Students see themselves as belonging to one institution – BSMS – and therefore expect to use one system when searching for books and resources, rather than the two separate library catalogues that they currently need to search. Members of BSMS also have access to the Brighton and Sussex University Hospitals NHS Trust Library. A future path could be to bring the NHS in to this service.

The CReDAUL project will…

  • Develop a set of requirements, and select either VuFind or Blacklight against these criteria.
  • Install the selected software and set it up for our needs
  • Add records from both Library systems
  • Carry out User needs analysis and testing, carried out by an academic who specialises in this area.
  • Write up our findings in a case study so that others may learn for our experience.

It is part of the JISC 12/09 Funding Call ‘Enhancing Library Management Systems’. It comes under Theme A ‘Use of new resource discovery interfaces’.

The project is based at the University of Sussex, with help from the University of Brighton and BSMS. It runs between 19th April – 15th October 2010.

Useful links

Blacklight Catalogue SoftwareBlacklight

VuFind Catalogue Softwarevufind