Drupal Site Structure

Revision as of 15:13, 23 April 2009 by Adam Franco (talk | contribs)


Our Drupal instance runs on a single web server with the majority of the site content in a single Drupal database. Some sites have their own Drupal database when they have significant functionality differences from the main site or are sites for affiliated or external entities.

The "sites" directory in Drupal controls what sites are available and what functionality is available to each site. The sub-directory "all" contains modules and templates available to all sites. These modules include those we consider necessary to run any Drupal site and include Monster Menus, the Content Creation Kit (CCK), Views, the fckeditor, and a custom version of the CAS module that we use to integrate single sign on. The "default" sub-directory contains additional modules that are used for the main site as well as templates for the main site and many sub-sites, like the Library and Academic Departments. Each additional site, like MIIS and NER has its own directory under "sites" and its own database.

Directory Structure

  • drupal
    • sites
      • all
        • modules
          • monster_menus
          • cck
          • views
          • fckeditor
          • cas
      • default
        • modules
        • templates
          • midd
          • museum
          • library
          • department1
          • department2
      • www.miis.edu
        • modules
        • templates
          • miis
      • www.newenglandreview.org
        • modules
          • ecommerce
        • templates
          • ner


  • The site becomes significantly simpler for us to support. Module upgrades only need to be done for code once, since there is only one server with one instance of the code. Furthermore, when modules are upgraded we only need to run the update script in Drupal for each subsite, of which there will be few. Patches and security fixes can be applied sooner and more efficiently, which will lead to better security and stability for the system.
  • There is a lower overhead for implementing backup and disaster recovery systems. One thought is that we could have a copy of the code and database running on a server at MIIS or in through a hosting company to be used as a failover. With one server and one code base, it is much easier to implement this plan. This also applies if we need to set up a load balanced cluster.
  • Developer interaction is not necessary to set up a new department or office site. If each department, office, and business unit had its own database and directory in the "sites" directory, a developer would need to set each one up, move the appropriate templates and modules into that sub-site and create the database. By having the majority of the content in a single database, we enable content creators to be able to create new sub-sites through Monster Menus in the web interface.
  • Content can be moved from one area of the site to another. Drupal stores content in nodes, each with its own id. If node 36 in site 1 needs to be moved to site 2, we need to check site 2 to make sure that it doesn't have its own node 36 and then resolve any conflicts. This is further complicated by Monster Menus, which assigns ids to page content that may, or may not, translate to node ids. Because of these complications, it is a significant undertaking to move content between sub-sites. However, by keeping this all in a single database, Drupal and Monster Menus allow content managers to move content within the IA through the web interface, without needing to contact the development team.


  • We need to be more careful with which modules are installed. Drupal loads its installed modules into memory and having too many can cause performance problems. For this reason, if a module is requested that will only be used by a small portion of the site content, we need to do additional investigation to determine whether we can allow that module to be installed.

Frequently Asked Questions

What happened to the separation of "the dotted line"?

You may recall in early discussions during the Web Redo Project we explained that the core site would move to being many fewer pages and that departments and offices would have more freedom in how they structured and implemented their web content. There would then be a "dotted line" separating the two, through which content moved via aggregation, if desired. This is still the case.

What is described here is an implementation decision for the platform that has a low impact on content creation or presentation. Even though all this content is in a single database it does not necessarily appear the same to those viewing it on the web, nor is it necessarily managed by the same group of people. The "dotted line" from those early discussions still exists in the form of content authorship, management, and presentation.

Can departments and offices still have their own look-and-feel?

Yes. In Monster Menus you can set which templates and content types are available to a part of the IA. Even though all the pages are in the same database, there is no requirement that a particular department's site look like the Public Affairs site.

Can I manage permissions for my department or office site?

Yes. Another feature of Monster Menus is delegated permissions management. Each department and office can work out on its own who will be updating their site and how it will be managed.

Module Evaluation

Because we need to be cautious of which modules are installed for this instance of Drupal, we are aware that the potential for conflict exists when you request a module for an area of the site you manage. Were your site in its own database, on its own web server, it would only be a matter of installing the functionality you request. But because we need to weigh your need for this functionality against the performance of the rest of the site for all users, we may not be able to complete the request. Here are the steps we take in making that determination.

Step 1: Is this the right tool for the job?

We begin by consulting with you on what you're trying to achieve. We want to make sure that the module you're requesting meets the requirements of the task. In some cases, there may be tools that are better geared toward your task that you hadn't considered or edge cases that the module you're requesting cannot handle gracefully. Oftentimes there are several Drupal modules that accomplish the same task, but do so in different ways.

Step 2: Have you tried another tool?

We run many different web applications at Middlebury. For each, we try to choose a "best of breed" tool that does one thing very well and run that, rather than have a "swiss army knife" application that does many things. For instance, if you requested a Wiki module for your site in Drupal, we would want to find out whether MediaWiki would meet your requirements. Another advantage of everyone using the same tools is that we have an internal community of other users, Helpdesk staff, student tutors, and developers who can answer questions about that application.

Step 3: Evaluate the shared need

Many departments and offices are trying to solve the same problems you are and may benefit from the added functionality you're requested. For example, you might request a newsletter management module be installed for your site, which is likely something that other sites would also use. If what you're requesting will help many people, then potential performance issues are offset by the module's utility.

Step 4: Evaluate the code

We need to ensure that anything we install will allow the rest of the site to continue working. We evaluate all new modules to make sure there are no obvious security issues, that the module does not perform tasks that would overwhelm the server, and that the functionality it adds doesn't affect the operation of other modules we have installed. Additionally, modules may need to be modified by our team to work with the Monster Menus module.

Step 5: Decide whether to add to the main site, or create a new sub-site

If we cannot add the module to the main site, we can create a new sub-site to store your site content that will run the new module. If we create this new site, you will be responsible for migrating your current content into that sub-site. You will also be responsible for migrating your content back to the main site, if you choose to do so at a later date. We would typically consider this step only in the event where you requested a module that significantly changed the nature of your site. For example, a Drupal module that added a presentation layer to the library catalog, like Scriblio does for WordPress, would be implemented as new sub-site.

Step 6: Install the module

We make any necessary changes to the module so that it works with Monster Menus and then add it to the collection of modules for the main site.

Powered by MediaWiki