Howto: Create a Family Blog using Drupal

My kids have grown up with blogs. Both my wife and I have blogs, and we often comment that we’re busy posting to those blogs when the kids ask us for something. My kids have expressed a number of times a desire to have their own blog. I want to encourage my kids to express themselves, and to exercise their writing skills, so I’m eager to allow them to blog. But I also want them to learn about appropriate expression, restraint, and context, so the idea of allowing them to share the details of their lives with the whole of the internet fills me with dread.

I don’t want to stand over my kids’ shoulders as they compose blog posts, because I know that that can influence the writing process. Instead, I would like a tool that allows the kids to compose posts on their own – over multiple editing sessions, if necessary – and which my wife and I can review before final publication. Thankfully, the Drupal content management system can provide exactly that.

Out of the box, Drupal offers two kinds of content: Stories and Pages. Stories are postings associated with a specific time, and the default Drupal configuration is to show stories on the front page of the site in reverse chronological order (newest first). Pages are postings that are not as tied to a specific timestamp (although they are displayed on the front page inline with stories). The easiest way to think of the distinction is that stories are time-sensitive topical items, and pages are longer-lived static content. For example, a post about what happened on my way to work today would probably be a Story, but a post about the intent of my website (say, an “About” page) would be a Page.

The default Drupal installation also provides an optional module for blog posts. The “blog entry” content type is similar to the Story content type, except that each user of the site can have their own blog, in which only their blog entries are shown. You can enable RSS feeds for each blog, too, so that readers can subscribe to the entire site or to a specific user’s blog feed.

Drupal’s tagline is “community plumbing”, and it’s clear that they built the software with an open community in mind. The default user permission system of Drupal is binary: either you can create some kinds of content, or you can’t create that kind of content. When building a site, the administrator decides which content types users should be able (or unable) to create. Editing content (as opposed to creating) is a little more flexible: a site administrator can allow a user to edit all items of a specific content type, only the items that user has authored, or none of that content.

Additionally, the default Drupal installation knows about only two kinds of people: anonymous visitors and registered users. Registered users are those people with accounts on the system that are logged in, and anonymous visitors are everyone else. For my family blog I needed a slightly more granular set of users, so I created roles named “administrator”, “family member” and “kid”. I granted to administrators all privileges, and assigned myself and my wife to this role. “Family member” is for adult users of the site (my dad, for example), and “kid” is obviously for my children.

The next step in building a Drupal-powered blog site for my family is to enable the Blog module, then grant permission for users to create blog entries and to edit their own blog entries. I modified my Blog Entry content type so that the default for these items is to not display them on the front page of the site.

The core Drupal system understands “draft” status, whereby an entry is saved into the database but not displayed to visitors. This allows an author to work on an item over multiple sessions. Unfortunately, Drupal only understands “draft” and “published” status: there’s nothing in between. So, using a stock Drupal installation, I would have to tell my kids to save all their items as drafts and to contact my wife or I when they have something finished. Obviously this is asking for trouble, as it’s all too easy to accidentally publish something prior to the desired parental review.

The Workflow module solves the draft/published dilemma for me. The Workflow module allows the administrator to construct workflows comprised of “states”. Content must pass from one state to the next, according to the rules of the workflow. In my case, I created a workflow called “Blog Review”, and assigned the Blog Entry content type to use the Blog Review workflow. I then added three states to the workflow: Draft, Ready, and Published.

The workflow module then allows me to define the rules by which content changes from one state to the next.

The description of the workflow goes something like this:

• Users in the "kid" role are permitted to create blog entries and save them as drafts. A kid may also specify an item as "ready for publication" immediately, without first saving it as a draft. Administrators and users in the "family member" role are permitted to create and immediately publish blog entries without review.
• For blog entries that are saved as drafts, kids are permitted to change the state to "ready for review", but they are unable to publish anything. Only administrators and (adult) family members are permitted to publish draft items.
• Anything that is marked "ready" can be reverted back to not-ready Draft status by a kid or by an administrator. This is in case a kid changes their mind on something, deciding that it's not yet ready for publication.
• Once an item has been published, however, only an administrator can change it back to Ready or Draft.

I’ve specified that the administrator role can see the Workflow permissions tab:

When composing or editing a blog entry, administrators see this:

When a kid composes a blog entry they see nearly the same options. The only difference is that they do not have the “Published” option. They can only select “Draft” and “Ready”.

My system is almost complete. I’ve found that the use of one more module makes this even smoother. The Actions module allows an administrator to define actions that occur when various things happen. The Workflow module has built-in support for the actions module, which makes things a lot better.

For example, when a user saves an item in state "Draft", the Actions module forcibly unpublishes the item. This is more a safety mechanism than anything else, but it gives me piece of mind that my kids' writing won't be published until I say it should be published. When an item goes from creation directly to "Published" (something only adult family members can do), the item is published and placed on the front page of the site. Remember: I modified my Blog Entry content type to not display to the front page by default; the Actions module allows me to put my dad's blog items on the front page but not my kids' items. When an item goes from "Ready" to "Published", it is published but not promoted to the front page of the site. In this way, my kids can have their own blogs but not attract undue attention to themselves (something my wife feels very strongly about).

You’ll note that there is an action labeled “Notify Editor” for the transitions to “Ready”. This is a custom action I created that sends an email to my wife and I whenever the kids mark something as “ready for publication”. The email contains a link to the item, which we can then review and decide whether it should be published or whether we should talk to the kids about the content.

There you have it: a family blog site using Drupal. Adult members of the family can blog unfettered, and kids can blog under parental review. My wife and I can feel comfortable allowing the kids to express themselves without being surprised by things we don’t think should be made public.