Organizing content in Drupal can be very liberating — or very frustrating, depending on what methods you're used to using.

Almost all information in Drupal is stored as a 'node', the basic unit of content. By default, there is no hierarchy or structure imposed on these nodes: they do not reside in specific 'sections' of your site, and different kinds of nodes (images, blog posts, news articles, etc.) are not automatically grouped or sorted into different groups. Rather than hard-coding specific hierarchies or styles of display, Drupal treats your content as a giant soup, with each piece of content having properties like a title and an author, a 'published' flag, a publication date, and so on. Specific kinds of pages, specific sections of your site, and so on are created by pulling up any content with certain properties and listing it.

Some examples can help clarify this concept.

  1. Default front page

    The default front page of a Drupal site (http://www.example.com/node) is a blog-style list of the latest stories posted. This simply pulls up any content nodes with both the 'published' and 'promoted to front page' flags set to true. If any pieces of content also have the 'sticky' flag set to true, they'll be moved to the top of the list, which is otherwise sorted by the date the content was posted. Different content types can be configured to have these flags on or off by default, and different user roles (editors, authors, etc.) may be given permission to override these defaults on a per-post basis. In a stock installation of Drupal, 'story' content has the 'Published to front page' flag set to true by default, while 'page' content (often used for 'about us' information, and so on) does not.

  2. Organizing content by taxonomy

    The taxonomy module has a number of uses, one of which is to allow keywords to be used to define sections, categories, and different types of content. For example, you might use taxonomy to set up a list of topics that news stories can be filed under. When the Taxonomy module is used in this way, the descriptive terms associated with a piece of content become just another property to use when organizing. The Taxonomy module provides a dedicated listing page for each one of these descriptive terms, displaying all the content associated with the term.

  3. Organizing content in blog style

    The Blog module implements group blogging features with just two additions: a custom 'blog' content type, and a set of new listing pages that show only blog entries, and blog entries by specific authors. When the module is enabled, http://www.example.com/blog becomes a sitewide blog, and http://www.example.com/blog/1 becomes the blog, filtered to show only posts by user #1.

  4. Organizing content using Views

    The Views module is a popular contributed (third-party) module that allows you to display content in pages and sidebar blocks using a wide range of criteria. For example, a list of the top 10 pieces of content that are published, but NOT 'page' content — can be sorted by the number of comments they've received and used as a 'most popular content' section.

The important concept to remember is that all content 'nodes' in Drupal are treated equally. Different sections of the site, and different kinds of organizational structures, are specifically built that way by site builders. These structures often consist of filtering down content based on properties like number of comments, creation date, author, associated keywords, and so on. You can have menu links to stand alone pages aliases with path module stand alone or nested. By planning your structure — and sometimes adding new contributed modules that layer additional properties on to your content nodes — you can build complex and powerful sites that grow with your organizational needs.

Content laid out by different custom types can also be a benefit in organizing and searching content in the content manager. Filtering by type makes finding a node much simpler in a website with many nodes.

Some other benefits of using different node types:

  1. Easier block visibility - display a block when the node viewed has this type
  2. Different URL schemes when auto-naming - EG: /node-type/*
  3. Theming by content type - content-type.tpl.php

Often a KISS (Keep it simple stupid) approach to designing content will be the best and allow easier maintenance or changes in the future.

Comments

jfall’s picture

jfall commented

The corollary to this, in Drupal 5, is that you need to spend some time carefully designing your various content types. In older versions there were basically a fixed set of content types, defined by the modules you had installed, but now, especially with CCK, the possibilities are endless. For basic sites, the built-in types will do, but the lure of custom content types is strong... (hmmmm, I hope CCK isn't 'the dark side')

I'm finding that building a Drupal site is far more similar to software design than traditional web site design (or rather, the web design is still there, but now there is an extra "programming-like" layer on top). Your content types are data structures, plain and simple. One of the first, and hardest, lessons of software design is that poorly thought-out data structures will destroy the most elegant designs - especially as the software scales up. One of the most relevant problems is that once a piece of data has been structured it can't change type. In the context of Drupal, this is very important - you have 300 Image nodes and then decide you need more flexibility than the Image module provides, you can't easily change the node type of those 300 Image nodes (well, bad example because some clever Drupaler wrote a module to convert Image nodes to a CCK Imagefield node, but the point remains - it is not trivial to change types.) Nothing against Image module - it is powerful and very simple to use, but it is worth thinking very carefully about your likely requirements before selecting or designing a particular node type to represent a piece of data (this from meager experience, but already much revising of data types due to evolving requirements.)

I am finding this to be especially important when designing CCK types with custom fields. If you don't get the fields right, especially if you are going to share fields across content types, you can get into big trouble - it is easy to add a new field to a CCK type, but modifying an existing field's underlying structure will almost certainly result in a loss of data, and thus some kind of data migration work - yuck.

My corollary to "Content, the Drupal Way" is probably "Content type design, the Only way"

loopduplicate’s picture

loopduplicate
she/her
Location Burning Token, California
commented

I can't understand the quote below. Can someone please edit it using grammer that is easier to understand?
"You can have menu links to stand alone pages aliases with path module stand alone or nested."

jebsabon’s picture

jebsabon commented

I think Jeff should explain this. But, this is what it means to me: ... Menu structures vary, and can be confusing. You can have menu links to stand-along pages. You can have menu links (etc?) to (page) aliases using the path (pathauto?) field or module. You can use the path module as your major (stand-alone?) approach. Lastly, you can organize pages into a structure by nesting one or more pages within another page (using links, for example. To me, Jeff is reminding me that web site structure can be arbitrarily complex. I hope this helps. Jeff, please come back an fix this if I've got it wrong.

Romejoe’s picture

Romejoe commented

Very Good summary!

I have to add that I personally feel to get into drupal is very frustrating and hard BECAUSE the structure is other than one knows from other fields. But once one has overcome this first problems and begins to see through the mist there seem to be no limits with Drupal because of the way it is structured.