Managing Multiple Sites in an EDU environment - A Case Study
by Jessica Straatmann
Drupal is a remarkably flexible content management system / framework that can be adapted to a wide array of use cases. The myriad of configuration possibilities to fit a project’s specialized needs is one of Drupal’s great strengths.
A frequent use case is the need for a large number of similar but not identical sites that will be supported in unison.
Drupal, along with its contributed modules, offers a variety of solutions to this problem depending on the level of similarity between the sites and how separate the administration of those sites needs to be. Larry Garfield of Palantir.net wrote a mavelous comparison of some of the most popular solutions in his post “Multi-headed Drupal.“ The lesson here is that a lot of solutions exist because a single solution is not the best one for every use case.
A Long Time Ago, in a Land Far Away
In 2006, I worked for a school at a university who was still managing most of its sites using static HTML. Each department managed their own site - usually hiring a student to make it. Needless to say, there was no common visual identity system or information architecture applied.
Because the websites were not the primary responsibility of any employee, they were not consistently updated. And as soon as the student who had built the site graduated, the abandoned site would sit completely forlorn until the cycle started again with a new student.
The school knew that this approach was not sustainable, so in 2006 they hired a design firm to provide a visual identity system and a consulting firm to recommend and implement a content management solution. After much deliberation, the school chose Drupal.
One of the selling points of Drupal was that it could support a large number of sites using a single code base. Most of the departments did not have their own IT staff, but they did have people with strong opinions regarding how their sites should appear and function. The content management system implementation was intended to both visually integrate the disparate sites and allow a very small central team of developers (1-2) to create and support the sites long term.
The departments were initially very reluctant to give up control of their fiefdoms. They no longer had direct access to their filesystems, and the overall package of functionality that departments were offered was limited to what the central developers decided to support.
However - this also meant that the sites functioned more predictably and were more secure. If content administrators had questions about how to do something, they had people they could ask. Users only had the access they needed to perform their job requirements.
Multisite was a good fit because all of these sites were centrally managed by a very small technology team, the sites had similar business requirements and traffic, and the content administrators in each site had limited permissions to reduce the possibility of one site taking down the others.
Drupal 6: the New Horizon
When we decided to migrate to Drupal 6, we created a new multisite installation using the new version of Drupal. All new sites were built in the new installation, and the Drupal 5 sites were individually upgraded and moved into the Drupal 6 installation over the course of a year.
Since multisite is natively supported by Drupal Core and we had limited our module use to well-maintained, stable contributed modules, updates were relatively straightforward.
To upgrade, we would develop a new Drupal 6 theme (giving clients a chance to update their design), copy the Drupal 5 database and files to development, run the update scripts, apply the new Drupal 6 theme, copy the updated database / files / sites directory into the Drupal 6 multisite installation on production, and then switch the domain name to point to that installation directory. The site would only be down for a few minutes as the DNS change propagated.
By the time Drupal 7 was released, we had roughly 50 Drupal sites spread across two multisite installations - one for Drupal 5 and one for Drupal 6. These sites were maintained and upgraded by a team of 1-2 developers who were also responsible for continuously developing new sites.
Because the sites shared a single base theme and 90-95% of the modules used were the same, multisite allowed us to easily keep all the sites updated using a single codebase - drastically minimizing the amount of time the team needed to spend on routine maintenance. The lack of duplicate code for each site also meant that the entire code base could be stored in memory using Alternative PHP Cache (APC) which improved performance.
Incremental version updates were performed using drush along with custom defined drush alias groups. The use of alias groups allowed us prioritize key sites by putting those sites into maintenance mode last, running updatedb on them first, and getting them out of maintenance mode before completing updates on less crucial intranet sites that might only be used during business hours.
But we thought we could make this even better.
Drupal 7, Multisite, and Features
For Drupal 7, we asked our department clients what features they would most like to see when they upgraded. We asked what frustrated them about managing their current sites.
We worked out a general set of modules, content types, views, and other configuration that could meet 90% of the departments’ use cases.
We packaged this configuration into a series of feature modules that could be enabled as needed. For example, the events feature contained an event content type along with a handful of calendar view options that each department could select to be displayed on the home page or on separate pages within the site.
To make the sites consistent in ways that were not features-compatible or that might need to be customized later, we wrote an installation profile that automatically enabled the necessary modules, created standard user roles, assigned standardized permissions to each role, created default panel layouts that could later be customized, configured the WYSIWYG editor, and performed all the other routine setup steps in creating a new Drupal site so that we did not have to remember to check all the checkboxes the same way in each new site.
All the Drupal 7 sites shared the same base theme built using the panels module. This meant that the school’s visual identity system was consistently applied while the use of panels allowed the development team to easily customize certain areas of the layout on a per-site basis.
Customization Does Not Necessarily Mean Custom
Clients, especially non-technical clients, often do not know what they want until they see it. They also are not usually educated on the latest design best practices (such as responsive design). Having a “menu” of layouts (provided by panels), color schemes, and functionality options (features) allowed our department clients to feel personal ownership of their sites while keeping the sites consistent and easy to support.
The end result: the development team could produce a new Drupal 7 site that matched the department’s requirements with a custom CSS-based sub-theme ready for approval/content entry in less than four hours.
Consistency => Maintainability => Future Growth
When I left the university to come work for Acquia, the school still had a development team of 1-2 people. This team was supporting and maintaining more than 100 Drupal sites across two multisite installations (Drupal 6 and Drupal 7) while developing new sites. They also personally supported hundreds of of individual content administrators.
This small team would never have been able to support this number of sites and this many users without the power of Drupal Multisite (plus features, base themes, etc).
Multisite is not the right solution for all use cases. If the sites have significantly different requirements or widely different traffic amounts, multisite may not be the correct choice. However, for a large number of sites that are similar, centrally managed, and only have a small support team, it can be a very valuable tool.