When I mentioned the other day that our site management system has more than 30 content types, you might have reacted in one of two ways:
1. Why on earth so many content types?
2. What's a content type?
Let's take the second question first, for clarity's sake.
In the beginning of the Web, there was only one content type, and it was the document. Typically coded by hand, it was without predictable form and structure. You can't build and maintain big websites with hand-tooled HTML, so very quickly we moved to publishing tools. These tools combined content with standard layouts (templates).
If you've posted anything on a blog, you've done something like this:
Blog posts represent a very simple content type. Other purposes require more complex structures -- additional fields -- and different templates for displaying the result.
Drupal has something called the Content Construction Kit. It's actually a family consisting of a little core functionality and quite a few contributed modules that let you create new content types and add all sorts of interesting fields such as validated date fields, embedded media objects, et cetera.
OK, so the technology supports multiple content types. Back to the first question: Why on earth so many content types?
It's easy to see good reasons for news items to be structurally more complex than a simple blog post.
But we also have some types of content you probably wouldn't think about at first.
Wire stories are an interesting case. We're not loading an AP Online feed into Drupal. We already have a system in place to support AP, and it's not so broken that it needs fixing. But we do need to manage and display AP components in the Drupal environment. So we have Drupal's FeedAPI RSS aggregator pulling in headlines and summaries. If you click on an AP headline in Drupal, you're sent directly to the AP server. This required a special content type and a bit of template work.
Promos are another. Every news site manager struggles with competing demands for promotional slots on the homepage for special projects and services, advertising sections, contests, et cetera. So we created a special content type to manage that problem. We made it simple to attach an image that is automatically resized. All the promos go into a library, so they can be temporarily removed and reused later. On Jacksonville.com the promos are displayed in a Javascript-driven carousel throughout the site.
Other content includes special types for various video players, feeds from other technology and content partners, items aggregated from websites in the community, podcasts, cartoons, Soundslides shows, and Tweets. We pull in Twitter postings from @jaxdotcom.
Drupal also creates content types for internal purposes, such as representing user groups, webforms, etc.
Now, what about that editorial content type makes it so special? I'll go into that in my next post in this series.
Comments
Django anyone?
Seems like you're making the case for the Django (http://www.djangoproject.com) framework.
Here's why not Django
Django is a fine development framework, if that's what you're looking for. I've watched Adrian Holovaty whip together some impressive demos on the fly, so I know it's a good RAD environment with emphasis on the R.
But here are two big reasons we're not using Django:
1. We're not Pythonistas and we are Drupalistas. We don't have any significant Python expertise in-house, and certainly not any Django experience. We do have expertise in building, configuring, scaling and optimizing Drupal websites. We've been running Drupal for several years on our community, radio, travel and other specialty sites.
2. We're not writing code unless we have to. While we are adding some Drupal modules of our own (most of which we intend to release), we're starting with a very capable and reasonably complete application that other people have already built. Nearly everything we're doing is configuration work and CSS/HTML styling, not hardcore PHP coding. Editorial web producers are actually doing much of the work.
What about DRY?
We don't ...
We don't have the first problem because our Views are pretty consistently using "is one of" in the "content: type" filter, rather than "is none of."
The second problem is much tougher. We do have a proliferation of Views templates that are essentially repetitive. We're starting to look at Active Template, although I suspect it just moves the problem around rather than solving it. What we really need is more Views display types so you can just select one that fits instead of custom templating.
It helps if you carefully create generalized views that accept arguments. By placing such a View in Panels Panes, you can pass information to tailor the results to a specific context. This greatly simplifies the templating challenge.
Because of our decentralized development model, we also have some repetitive CSS patterns that we're now cleaning up. Going forward, we're dealing with the CSS issue by moving to a top-down model of defining the CSS, based on design comps, before the views are built.
Panels
Re: Here's why not Django
Two answers
Anonymous: You're assuming the wrong problem. We're not trying to make programmers happy.
Tim: We're using D5, and we're just beginning to look at how Panels can be useful in the context of individual nodes. We have extensive packaging options built in to our editorial node type without requiring panels -- we use Node Relativity for creating links to other content, and some custom code for quickly embedding videos, slideshows, stock market linksets, etc.
One thing Panels can buy you is a layer of easily controllable caching of block output.
Re: Two answers
I like it. Great post
Thirty content types? Eee, you have it easy!
We do have expertise in
Drupal vs Wordpress
Create your own framework