Lately, I have heard Drupal referred to as a “framework” in addition to a content management system. After building several Drupal sites, I would have to agree. A core Drupal installation gives you very little to start with. However, with the help of widely-used contributed modules, you can build anything from a personal blog, up to https://www.grammy.com or https://www.whitehouse.gov.
Or https://www.duke.edu. Duke University’s information technology units have historically followed a decentralized model. As a result, Drupal isn’t “the” CMS at Duke, it’s one of three supported by the central web services team. WordPress and Cascade Server are the other two, and many others can be found across the university as well. That said, however, Drupal is gaining in popularity, and increasingly more division and department websites at Duke are built in Drupal. We also redesigned our institutional homepage in Drupal in the fall of 2009.
Duke’s centrally-hosted Drupal instances run in a LAMP environment (Linux, Apache, MySQL, PHP). However, Drupal can be installed on a Microsoft IIS web server, and it can use a PostgreSQL database - although these aren’t recommended. Our homepage receives around 27,000-30,000 visits per day, and it handles this with ease.
A simple Drupal installation is fairly straightforward: Download the most recent version from https://www.drupal.org, put the files on the web server, create a database, and run the install script. However, Drupal is very bare-bones out of the box; the current version does not even include a WYSIWYG editor. It is almost always necessary to supplement the Drupal core with add-on modules. And, if you do not find a contributed module that fits your needs, a developer with decent PHP chops can write a custom module, and even contribute it back to the community if desired.
This can be daunting to people who are accustomed to getting more out of the box with their CMS. However, the bare-bones core is actually a boon to developers, as it makes Drupal very easy to customize. That said, it’s tempting to go overboard with contributed modules. However, installing a large number of modules can be resource intensive and substantially slow your system down, so you have to find a happy medium.
My main caveat to anyone considering Drupal is the need for adequate development resources, preferably in-house. While it is certainly possible to get a Drupal site up and running without HTML or programming experience, it would be a very difficult task and your site will mostly likely not look very good, to be perfectly blunt. Templates are created with HTML, CSS, and some PHP. You can either build your own templates, or install an existing theme. If you want to create your own template, you don’t need to be an expert in PHP but it is necessary to have a basic idea of the syntax. PHP is not needed to install modules, but if you want to embark on creating your own, then it’s a must.
The central IT unit at Duke has three developers and two systems administrators who work directly with Drupal; individual school and department units have their own IT staff and are responsible for their own Drupal installations. Our central web team is always building new websites, and maintaining Drupal is only one of our responsibilities. Once a site is up and running, our only involvement is upgrading Drupal periodically or building additional features onto an existing site if the client requests them.
Drupal is free and open source, and we host our sites in house. Therefore, all of our costs are absorbed into hosting costs and staff salaries. This, of course does not mean that Drupal has been completely free for us. As a case in point, the Duke.edu redesign consumed a large percentage of three developers’ time for over two months, which kept us from working on other projects.
Drupal has an option for multi-site installation: running multiple websites off of the same code base, with each site getting its own database (it’s also possible to run multiple sites off of the same database or to share tables; for example, a user table). Multi-site simplifies upgrades substantially. We have some websites running off a multi-site install, and some standalone instances. This is due primarily to our decentralized organizational model than a limitation of Drupal, per se.
High availability was one of our main concerns when we first started thinking about using Drupal for the Duke.edu site. Since content is stored in a database and files are PHP, the site is already more resource intensive than one comprised of flat HTML files. There are a number of caching mechanisms built into Drupal as well as additional modules that can boost the caching further. We enabled these but just to be on the safe side, we also used GNU Wget, a tool for retrieving files and outputting them as flat HTML. When site visitors go to the Duke.edu front page, they are actually viewing a flat HTML file rather than dynamic PHP output. Wget is triggered regularly by a scheduled cron job so to the content stays fresh. This cuts down on page load time substantially.
Duke uses a Google Search Appliance and a custom people directory search program. Because these systems were already in place before our redesign, we chose to wrap them in the site template, rather than build them into Drupal itself. However, we were able to incorporate data from other systems into Drupal directly. We use a module that not only pulls in items to the homepage from the news site and institutional calendar, but also allows content editors to cherry-pick which items should display. They enjoy the ease with which content is imported from these other systems, but also the editorial control the cherry-picking affords them. Drupal has a module for incorporating Shibboleth authentication, which Duke’s Division of Student Affairs has implemented on their installation.
Since Drupal is open source, there is no official support built in. That said, however, the Drupal user community is wonderfully helpful. https://drupal.org has links to tutorials and documentation as well as the user forums. I initially found the myriad resources on the internet to be sensory overload, so I actually found a book to be most helpful when getting started (“Using Drupal” published by O’Reilly, was my favorite). Lullabot provides a variety of instructional videos and training as well. I’ve also found my local Drupal users’ group to be an invaluable resource. Even though most Drupal developers I’ve met through the group work outside of higher education, they have been very helpful when troubleshooting and brainstorming.
Drupal is known as “developer-friendly,” in the sense that it is highly flexible. One of my favorite aspects of Drupal is that it allows you to customize the format of your data to the logic of the content, rather than squeezing your content into a predefined set of form fields in which it might not logically fit. Editors have reported to us that content entry feels more intuitive to them in Drupal than in more rigidly defined CMS’s.
The downside of this is that you get very little out of the box with Drupal, and the developer learning curve is relatively steep. There is a lot of configuration that needs to be done at the outset just to get a site off the ground. It’s crucial to have a Drupal developer (if not more!) on staff, or the resources to hire an outside firm.
However I would be remiss if I did not mention Acquia, a company that provides products, services, and technical support for Drupal, and founded by the creator of Drupal. Acquia offers various pricing models with differing levels of support and maintenance, all the way up to a fully-hosted option. I personally have never used Acquia, but have heard only good things about it. Acquia might be a good option for organizations that would like to use Drupal but do not have resources available to keep up with support and version updates.
As much as I love Drupal, I will be the first to admit that it is not the best tool for every website — which is why we support three CMS’s in our web office. A small standalone departmental site consisting of only a few informational pages and maybe a listing of news stories? I’d probably build that in WordPress or Cascade Server because the structure of the site is simple and I could build it much more quickly in either of those than in Drupal. But a website in which the clients want a blog, a database of case studies that can be searched in a variety of ways, a discussion forum… and they’ll probably want to add additional functionality later? That site would be an excellent candidate for Drupal.
Our next steps for Drupal at Duke? Build more Drupal websites, of course! All kidding aside, our major priority is investigating ways to speed up the rollout and upgrade process for our standalone instances, as well as developing a slightly more streamlined hosting model overall. We are also looking to establish a more cohesive Drupal user community at Duke. Increasingly more departments and organizational units are adopting Drupal as their CMS. But because of our decentralized IT structure, Drupal developers at Duke often operate in isolation from one another. The global user community is one of the greatest benefits of Drupal, so we need to take our cue and foster greater camaraderie among Drupal developers within our own institution.