Targeting Communities Through Site Segregation

Websites that service a number of target communities are faced with the challenge of providing contributors with simple and consolidated ways to add content, while providing intelligent ways for target communities to access content they want (or are allowed) to see.  Drupal provides many different ways to contribute, control and display content, so how do you choose the best way?

In terms of input, less content types is often better.  Let's use the old "News and Events" example.  You could create a content type for each target audience and create a view page that lists the nodes of that content type (e.g. student_news, faculty_news, staff_news, etc.), but do you really want to create duplicate content types for each audience?  A better way would be to have one content type with a way of tagging each node with the intended target audience(s), thus allowing you to create views that filter your nodes by both content type and target audience.  Sounds easy.

But it's important to recognize the difference between content that should be seen by a specific audience and content that can only be seen by a specific audience.  In other words, the difference between content filtering and access control.  So you could use taxonomy to add a Target Community vocabulary and maybe even toss in tagging for topic keywords, but you might also need to implement node-based access control to provide content contributors a way to target a community and limit access to specific roles and/or users.

There are a number of Drupal modules to assist with granular access control.  The Nodeaccess module adds a Grant tab to nodes that allows contributors to grant view, edit and delete rights per node for both users and roles.  The similar Content Access module provides the same control either per content type or per individual node.  The CCK Password Field provides a more simplistic method.  There's a ton of modules providing pretty much every type of access control you can imagine.  One important consideration, however, is that access control modules tend to be invasive as they often replace Drupal's native permissions.  Scary at best.

On the other side of the coin is how your target communities will view content.  Again, there are a number of ways to accommodate this.  Both Views and Panels provide filtering and access control tools for targeting contend by vocabulary term or role.  So you could easily create, for example, views page and block displays that only show content tagged for students.  This can, however, become quickly unmanageable, when you consider all the blocks that you'll have to shuffle for each of your target communities.

Another approach is to set up specific sites for each of your primary communities.  At first glance it seems crazy to propose managing multiple sites for the same content, but this gets feasible when you look at the Domain Access module:

"The Domain Access project is a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database. The module allows you to share users, content, and configurations across a group of sites."

So you could set up a number of community-specific domains such as the following:

• www.example.com (root public site and primary landing page)
• my.example.com (customized interface for authenticated users)
• students.example.com (site targeting prospective students)
• alumni.example.com (alumni social networking site)
• mobile.example.com (customized for mobile devices)

Yet another approach to toss into the mix is using the Context module to section off site content based on its context within the site.  Panels is often used as an alternative to regions because it’s easy to see how blocks and regions can get really out of hand on a large site.  This video podcast demonstrates a way of segregating site content through the use of the Content module, regions and blocks.  So we can aggregate content from anywhere on the site into sections using many different criteria.  Very cool and definitely worth a head-to-head comparison with Panels.

Regardless of the path you take, you'd better pick the right one during the design phase of the project, because the choices outlined above are a one way trip.