At MPOW we’re hoping to migrate the library’s static HTML web site to the Drupal CMS. We’ve been using Drupal successfully for a year and a half for an offsite affiliate project and for a SEPA grant-funded project.  We have access to develop the current site using .NET when we want, but we don’t have the resources to do any significant development. Lack of PHP (and MySQL) support on campus is the only thing that has kept us from making the jump to Drupal.  While we have an ample ‘Nix VPS to host it on, I’m concerned that we don’t have the resources to maintain and update Apache or the PHP and MySQL frameworks.

Our current Drupal projects are hosted on inexpensive shared hosting which has been mostly sufficient for what we need including shell access, SVN, CVS, and Apache .htaccess capability. I don’t have to worry about updates to Apache, PHP, MySQL, or the OS.  If we were to host the library’s web site offsite as well, I’d want the best of both worlds: reliable support, a managed environment, dedicated RAM and processor cycles, but also full access to Apache’s httpd.conf.  Pair Networks is attractive for all these reasons. Also, our current host doesn’t support Java/Tomcat/Jetty which means we’d still have to host Solr separately on campus and manage access to it from other applications. Tomcat or Jetty support on the same host would be nice, but it’s not a deal-breaker.

Why do we want to migrate to Drupal? For many of the same reasons hundreds of other libraries and thousands of organizations do:

• a huge, and growing, user community,
• an overwhelming number of user-contributed themes and modules that extend Drupal’s core functionality,
• Drupal’s flexibility for modeling and displaying content,
• Drupal’s taxonomy and tagging support.

But these are all means to the end. In the end, we want our web site to deliver information well and make it easy for people to find what they want or learn how to get what they want.  David Lee King, Topeka’s Digital Branch Manager, recently offered 10 reminders that we strongly identify with.

Based on our experience with Drupal so far and conversations we’ve been having for a long time, here are some things we want to do.

• Make it easier and more enjoyable for our staff to post or update content to the web site.
• Improve how we provide news about library resources and services. Patrons can subscribe by email or RSS to various “channels”, e.g. type of content, subject, author.
• Advertise “featured” content and give our “marquee” an extreme makeover that showcases what’s happening.
• Create subject guides and more audience-oriented channels of content without unnecessarily duplicating content. Example, “you’re into pathology? Here are the best available resources for you. Oh, and here’s what’s new in PubMed and here’s a librarian to contact. In the hospital? Sure. Here’s the set of online clinical resources, image collections, and what we have on the shelves.”
• Integrate metadata from Voyager, the institutional repository (DSpace), and Serials Solutions using the Extensible Catalog Drupal toolkit to create a better discovery layer across all our resources, i.e. open up the silos.… And to put it into context with the rest of our content.
• Integrate content from other sites.
• Manage FAQ’s.
• Improve library instruction, i.e. “where-to-find, how-to-use”, without duplicating content.
• Encourage conversation and feedback by giving patrons the ability to comment on the web site or in whatever social network(s) rule the day.
• Distribute content between multiple “affiliated” sites, between the Library web site and project/partner sites.
• Support mobile devices.

We’re confident we can accomplish them with Drupal (and yes, Solr) in a relatively short amount of time.

ApacheSolr provides search and faceting.

Better still, HILCC is licensed under Creative Commons.

Ægir is a new set of contributed modules for Drupal that aims to solve the problem of managing a large number of Drupal sites. It does this by providing you with a simple Drupal based hosting front end for your entire network of sites. To deploy a new site you simply have to create a new Site node. To backup or upgrade sites, you simply manage your site nodes as you would any other node.

We’ve been successfully running multiple sites on a single development installation for several months.  Presently we only have a single site in production, but will likely be ramping up soon to roll out one or two others. Aegir should certainly help distribute administration of those sites.

Context sounds like another useful module. We currently use Panels module in Drupal 5 which has a very nice, yet somewhat limited, built-in context feature. I have a hate-love with Panels and would like to avoid using it in cases when I only need context without the accompanying box model.

Spaces module appears to go hand-in-hand with Context.

Spaces allows features (a blog, calendar, casetracker, shoutbox, gallery, etc.) to be enabled and customized in different configurations in different spaces…. Spaces features are essentially context definitions with some additional metadata. Once exported to code, spaces features can be bundled with exported views, implementations of the space settings class, and other niceties to create packaged, ready-to-go features.

Not exactly sure what that all means yet. It’s still in alpha for Drupal 6 only at this point.

FeedAPI is another developmentseed module we have been using. FeedAPI has been very handy for aggregating news from the likes of MedlinePlus, CDC, and others, and then turning those news items into nodes.  Nicely done.

Finally, the eXtensible Catalog Drupal Toolkit is not a developmentseed project, but one I’m anxiously awaiting any release of. Mlen-Too Wesley, one of the developers, gave a lightning talk in February at Drupal4LibCamp. There’s also a screencast. The XC Project just announced release of their OAI and NCIP Toolkits so hopefully the wait won’t be terribly long.

Taxonomy Filter.  This seems like the ticket.  Works with Panels.  Lots of options exposed in each Vocabulary’s settings.  Even supports a tag cloud using the Views Tagadelic and Tagadelic modules.  I installed Tagadelic and they work nicely.

Taxonomy DSS is the right idea, but doesn’t appear to obey any of the panel settings for the Taxonomy DSS block.  The resulting list just spits out the current taxonomy with all other terms nested.

Taxonomy Menu with DHTML Menu.  Does what it sounds like.  Not what I need, but may come in handy later.

Refine by Taxonomy.  Creates blocks, but blocks don’t work intuitively in Panels.  Also tacks additional term ID arguments onto the URL.  Don’t have time to figure this one out.