Skip to main content

The basic concept of blogging with Drupal

One beginner's mistake that's made often, is to enable the blog module, in the hope of it automatically setting the content management system up in "the right way". This is exactly what the module does not do at all. Despite its name, the blog module only adds support for tracking individual authors and posts on community websites. It is definitely not needed to build single user blogs and should not be used for them.

Before trying to configure Drupal to work as a blog, it is a good idea to stop and think for a moment about what a blog is or rather, what it is suppose to do. While there is no strict definition for the term "blog", most people will expect the following core functionality:

  • The ability to publish individual articles on a variety of topics, which are not necessarily related to each other.
  • The ability to group individual articles by tagging them with keywords and a way to navigate by these tags.
  • Articles should record their date of publication and sort by date.
  • A chronologically ordered list of posts on the frontpage with the most recent post being on top of the list.
  • An RSS feed.
  • A sidebar, containing various controls for navigation.

The good news is, Drupal has support for all of this right out of the box without requiring any additional modules installed, but it may not (especially not to novice users) always be obvious how to get the CMS to behave in the desired way, as Drupal does not enforce any methodology.

When planning to blog, the first thing to take into consideration is how to publish content, or to be more precise: How to tell whether a specific page is indeed a blog post or something else that should live outside of the blog context.
This might seem like a rather odd thing to think about. After all, what other kind of content could there possibly be except blog posts? Pondering that question for a moment, however, quickly yields the answer that there might be a need for having an imprint, a privacy statement or the potential for publishing temporary pages in order to test things.
So, what quality of a page plays the decisive role?

With Drupal, content is always typed and types are implicitly assigned, when new nodes are created. This allows for breaking down the initial problem by simply stating that content types fall in either of two groups. One group is to be used for blogging, while the other is not. The only remaining question now is, what makes a content type a member of one group and not the other?
Back to the list of core requirements. A blog should have a chronologically sorted list of recent posts on it's frontpage. So, to reverse that statement, a page becomes a post on the condition of it being featured on the frontpage. In other words, those content types, which send their associated nodes to the frontpage by default are the blog types. This point of view has two important implications in order to prevent chaos:

  • The frontpage is in fact reserved for blogging.
  • The "promoted to frontpage" option must be set globally for the content type and may not be overridden for individual nodes.

Drupal actually comes preconfigured with a content type that is already setup accordingly. This content type is called Story. The other content type, Page, can be used for publishing any non blog material.

Besides featuring on the frontpage, there is one other condition, blog posts must meet in order to be considered as such. Looking again at the list of requirements, they are also suppose to be classifiable by using tags. The concept of tagging is called "taxonomy" in Drupal and works in a less intuitive way due to its flexibility. The main source of confusion here being that tags, or rather "terms", always live in containers called "vocabularies", of which there can be an arbitrary amount. This raises the question of how many vocabularies are required for a website. The answer to this question is non trivial (see tag clouds and/or categories for a further discussion on the matter). In the easiest case however, one vocabulary suffices on the condition, that all content types, having the "promote to frontpage" property checked, are also associated with it.

Summary:

  • Use the Story content type for writing blog posts and Page for standalone pages.
  • The "promote to frontpage" setting is what makes the distinction between blog content and non blog content. Never override it on individual posts. Always go with the default setting of the content type.
  • Create a vocabulary for tagging blog posts with keywords and assign it to the Story type.
  • When adding a new content type (e.g. in case some blog posts require a special layout/theme of their own), just mark it as a blog type by checking the "promote to frontpage" property as its default setting and associating it with the blogging vocabulary.