How to protect your website from your intern


Back in August 2014, there was an intern working for a Washington, DC think tank called The Center for Strategic and International Studies. We don’t know a lot about this fellow—how long he had been working there, who he worked under, what he was supposed to do there. However, thanks to the wonder of modern technology, we do know one thing about him. Using his employer’s Twitter account, he published this in response to a tweet from well-known non-profit Amnesty International:

I’m guessing his major isn’t Diplomacy.

The tweet was taken down soon afterward, but not before hundreds of people had taken screenshots of it. The organization had to apologize profusely (of course), disavow the comment, and suffer a fair amount of damage to their hard-earned reputation as “the number one think tank in the world for security and international affairs."

What does this have to do with websites, you ask? Just like Twitter, a well-made Drupal website makes it easy for anyone with a login to publish stuff on behalf of your organization. It’s straightforward to manage blog posts, news, press releases, homepage feature stories, and so on. That’s great, because you likely feel a lot of pressure to keep fresh content flowing into the site, and the ability to hand some of that responsibility to other people is a relief. But of course, it raises the question of quality control. How can you share the responsibility of writing, but avoid the danger that the words “suck it” might dance across your homepage some August morning?

I’ll describe the solutions that we came up with for a couple of clients who asked just such a question.

Workflow 1: Just One Kind of Content

The Radcliffe Institute for Advanced Study at Harvard has a small communications staff who writes most of the information on their site. However, the staff of the Schlesinger Library—which houses the Institute’s collection of scholarly material focusing on women’s studies—wanted to be able to highlight interesting items from their catalogue in the “Picks and Finds” blog.

We built them a workflow with two levels of permissions: a “blogger” can create or revise a blog post, but can't publish it. That unpublished material remains invisible to the regular site visitors until an “editor” logs in, makes any necessary changes, and publishes.

The tricky part of this workflow, at least from the standpoint of making it clear to bloggers and editors, is the “revise” ability. If you’re one of those bloggers, and you’re allowed to change a post but not to publish that change, that means that the system has to keep track of at least two versions of that post: the one that everyone can see right now, and the newer one that’s waiting in the wings until an editor okays it. Here’s a typical workflow:

  1. A user with the “blogger” role, whom we’ll call Mr. Library Blogger, logs into the site and creates a new blog post.
  2. He tells the communications person (Ms. Website Editor) about it, asking her to publish the post.
  3. Ms. Website Editor looks the new post over and likes it; she publishes it.
  4. Mr. Library Blogger realizes that he forgot to add something! He logs back into the site and changes that post.

Now there is a published version of that post, and Mr. Library Blogger’s updated-but-unpublished one. Here’s how that looks to Ms. Website Editor:


Ms. Website Editor can click the new revision to either polish it up before publishing, or just publish away. In either case, she has:

  • allowed Mr. Library Blogger the freedom to write what he wants to
  • freed herself from having to write things for him
  • kept control over the tone of her website!

Workflow 2: Many Writers, Many Content Types

We’ve just discussed a pretty simple workflow example. Another client of ours, the non-profit Management Sciences for Health, needed something more complex. They strengthen health care systems by bringing improved techniques to places that need them most. Again, there is a small communications staff; however, MSH is a thousands-strong organization, with experts of every stripe working just about everywhere in the world. Many of those smart people want to add their voices to the organization’s site, and their expertise comes through in what they write—but those communications people at the home base still need to ensure a reasonably consistent tone.

To enable their workflow, we split the content up into logical content types, including Countries, Projects, and Stories (i.e. news stories). We then created a role for each content type—i.e. "Country Editor," "Project Editor," and "Story Editor." People with that role are allowed to create or revise content of that type, but not to publish it. Splitting up the site in this way lets us dole out the ability to change things in a nice, granular way. And then there is the top-of-the-food-chain role, “Content Admin.” People with this role (and only these people) are allowed to actually publish content, of all types.

But what if someone were hard at work adding, say, news stories, and forgot to let those content admins know? It would be very easy for important information to get stale, waiting for approval that would never come. So we added a “Notify Admins” section to every content-editing screen. This consists of a checkbox for every person in the system with that Content Admin privilege—whoever you check will receive an email as soon as you save.

Carl Content Admin: the man was born for this job.

Workflow for All!

Much of the code involved in creating the functionality above came from the fantastic Revisioning and Rules modules—if you’re working on creating this sort of thing for your own site, of course check those out. I mention this to be sure to give credit where it’s due, and to underscore a point I make frequently about Drupal. It strikes an amazing balance between giving you a lot of power as soon as you turn some new module on (e.g. the Revisions module), and letting you subtly change that power where you need to (emailing specific people upon the creation of new revisions).

What this means for our clients is that whatever the shape of their organization—research institute, large non-profit, or, I don’t know, unfortunate Washington think tank—we can help keep anybody from getting too drunk with the power that comes from a really good CMS.

Just imagine how much worse he would be with the power of Drupal at his fingertips!

Share the Love