Drupal: MLibrary's Future CMS
July 24, 2008
The University of Michigan Library is in the process of a major site redesign. Part of this design is moving -- at long last -- from static pages built on SSI to a full-blown content management system. We started with a review of the (mostly open source) CMS software landscape, and winnowed this list down to nine candidate systems worth a deeper look:
We took a look at each of these in some detail, taking into consideration programming languages and local expertise, amount of documentation, vibrancy of the active developer community, comparable "peer" installations (either in other libraries or at other similarly large-scale sites), and a very subjective review of how the admin and authoring interfaces acted. We summarized our findings in a spreadsheet:
After this first pass, we ended up with a short list of 3 tools, the ones with the highest average score:
We then set up out-of-the box test installations of these three finalists and compared them in terms of workflow (our final designs weren't ready, so we didn't focus on making the test installs look "right"). We arranged phone conversations with library IT folks who were using these tools. And in the end, we selected Drupal. While the other two tools had strengths, we ended up deciding against Joomla! because of what we perceived as a surfeit of security problems over time with frequent releases to patch bugs or security holes. We liked Plone, as well, but we felt taking on a new programming environment (Python) for something as critical as our web presence was not sensible.
In the end, though, it was Drupal's strengths in terms of its modular construction, very lively development community, and the number of large academic libraries using it that led our decision.
While I use Drupal for both http://openurl.code4lib.org/ and http://jangle.org/, I have a total soft-spot for Daisy. I was hellbent to get Georgia Tech library to use it for their CMS (since I was designing the catalog replacement with it, anyway).
I understand the appeal of Drupal's community that's what drew me to it for the site above (plus, cheap web hosting... whattayagonnado?), but Daisy's versatility is just amazing.
Of course, it would require some front-end development, so there's a cost...
Posted by: firstname.lastname@example.org at July 24, 2008 10:03 PM
I'm in the middle of exactly the same thing: setting up and configuring Drupal for our small community college library.
At first we tried Mediawiki, but we were finding too often that we needed to create workarounds to make it fit our needs. I suggested Drupal, and we took the plunge.
Drupal is awesome for this kind of environment. Anyone with decent knowledge of html, css, php, and MySQL should have no trouble developing a very functional Drupal site.
I'm interested if you plan to integrate your catalog system with Drupal, and how you will handle the server load Drupal places on high traffic sites. We're finding that PHP has suddenly become a memory hog, and we're still in development.
Posted by: email@example.com at July 31, 2008 04:55 AM
For now, we're not planning on true integration of the catalog into Drupal. We're planning to smooth over the differences in interfaces between our Ex Libris Aleph catalog and our new library web site in a couple ways. First, we will pull search results, via the XML interface, X-Server, into Drupal-generated pages so the templating will remain the same. At the same time, we are experimenting with a next-generation OPAC interface to Mirlyn that we plan to skin like the Drupal site.
As for traffic load and PHP... We'll be figuring that out as we build our development site. Any suggestions from your experience?
Posted by: varnum at July 31, 2008 08:17 AM
All we've found so far is that modules can be huge memory hogs with PHP. We've had to increase the PHP memory limit a few times now.
We haven't done any heavy load testing so far, and I'm not sure the small user population here really justifies it anyway.
I'm working with our Director/Systems Librarian (like I said, small college) to get in contact with Ex Libris to find out about the XML options with Voyager.
(Update: Just got off the phone with Voyager staff. No documentation on Voyager XML, no API until we upgrade to v7.0)
Also, there's a Drupal in Libraries group in case you haven't seen it; they seem to be pretty active: http://groups.drupal.org/libraries
Please feel free to email me if you would like to collaborate on this further. I'm excited to learn more about how other libraries are using drupal! Do you plan on having this up and running by Fall?
Posted by: firstname.lastname@example.org at August 6, 2008 06:55 PM
Our target date is the end of December for the site migration. We have a lot of work ahead of us!
Posted by: varnum at August 7, 2008 08:13 AM
I don't understand why most people stop for opensource CMS if security is an issue?
Posted by: email@example.com at October 3, 2008 06:31 AM
I think security is a concern with almost any system. With open source tools, there are many more people poking at it and finding ways to close any holes that exist. With traditional software, there are still many people trying to poke holes, but only the vendor who can patch it. Generally speaking, I prefer the former.
Posted by: varnum at October 3, 2008 05:57 PM