You are here

Building a College Website

The College of Life Sciences at the University of Dundee recently launched a new website based on the Drupal Content Management System. What follows is a description of how the site was built and the hurdles that we have had to overcome / are still overcoming in order to promote the College and boost awareness.


The College of Life Sciences has a somewhat complicated organisational structure. The College itself is split into two schools (School of Learning and Teaching, School of Research). The School of Research is then split into twelve different divisions covering a variety of research areas. Each division is then split into a number of different research groups which total approximately 80.

Each of these distinct areas (schools/divisions/groups) can have their own site (same domain for the most part but different directories, but we also need to be able to cope with different domains). However there is a lot of information that is common to each site that needs to be shared between them. This ranges from staff profiles (which are imported from an external source) to news and event items. Much of this information is maintained centrally, but needed to be filtered to each site automatically. Additionally, we also needed to provide individual site administrators with the ability to create their own news/event/content items that were specific to their own site.

To top it all off, we wanted to provide a staging system that separated the live site from the staging site to reduce the likelihood of problems on the staging site affecting the live site.

How we did it


Our Drupal environment is made up of three servers: live, staging and development. In order to synchronise information between these servers we use scripts that make heavy use of drush. At their most basic these scripts copy the database, then the files and then turn on/off various modules as required. This allows us to mirror current information onto the development server for testing new themes/modules in a semi live environment so that we can be relatively sure they will work when copied onto the staging/live servers. Every hour everything from the staging site is copied across to the live site.

The live site is isolated from the rest of our infrastructure. Nobody has access to it, with information being pushed to it via drush from the staging site. In the event that the site is hacked, it should be a case of synching with the staging site to remove any problems. It itself sits behind a proxy server to further speed things up.

Drupal Install

We have a single Drupal 6 installation that manages all our different sites. Using a combination of modules such as Virtual Sites and Organic Groups we are able to deliver the look of different sites (same domain, different directory).

Managing Content

Utilising the CCK module, different content types were created for each distinctive content type (news, events, profiles, etc) and taxonomy created to represent the structure of the College (schools, divisions, groups, etc). As each content item is inserted, it is tagged with the area to which it belongs. As each Organic Group is created, it is tagged in a similar way which allows us to design views that can be used in different sites to show information that is related to that site. It also allows us to enable users to create their own content items which aren’t replicated to other sites.


In order to boost performance we use the Boost module. This works really well for us as most of our traffic is anonymous. However it does pose problems when information is being replicated across to the live site. We came across an issue early on where old information wasn’t being expired when it was updated on the staging server and transferred to the live server. After many days of digging into Boost we discovered it was because of the way that it flagged stale content. After much fiddling we managed to fix this problem.


“Could you do it this way?”

Standardising views is a great idea in principle, but we’re starting to find that each group wants things slightly different. Unfortunately this has resulted in a large increase in the number of views we have to look after and is starting to get a bit unwieldy. Whilst not a huge problem in theory, it goes against our mantra of “develop once, deploy often”.

Modules, modules everywhere…

As we bring more groups onto the system we inevitably find that they want to do “new and exciting things”. The beauty of Drupal is that if you want to do it, there is most likely a module out there that will do it for you. However it means that our codebase is increasing, things are starting to slow down, and makes for doing routine upgrades a real pain. Whilst Drush goes a long way towards making that easier, testing each site after each upgrade is tedious at best.


As I mentioned above the Boost module works well for us at the moment as most of our traffic is anonymous. However we have plans in the future for making the site more interactive and personalised. As Boost won’t cache authenticated content, we are going to have to look at other ways of speeding the site up once we get to this stage.


Whilst our plan for staging servers seemed sensible at the time, as we move towards a more personalised experience for users, it becomes impossible to work with. How exactly we replicate end user content from the live site to staging without overwriting anything that has been input since the last sync, and vice versa, is a tricky beast to figure out.

Future Plans

For our first foray into a Drupal site we’re quite happy. Compared to the system that we had it is infinitely more configurable and we can set up pretty much anything we want. However with potentially over 100 clients all wanting different things, our current implementation is going to struggle. We could limit what we’ll implement, we could insist on a one design to fit all, but with the web changing so quickly and user requirements changing all the time, we need an infrastructure that can react quickly and easily to those changes.

We’re currently looking into implementing Aegir. If successful this should give us the ability to spin out Drupal installs in a managed way. What we also need to get better at is trying to put as much configuration into code as possible in order to realise our “Develop Once, Deploy Often” mantra. Through a combination of Features and upcoming improvements in Drupal core for this kind of thing, it should be manageable.

The big hurdle to implementing Aegir is that it breaks our ability to share content between sites. How we go about that I’m still investigating, any and all suggestions very welcome!