30 content types? What?

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

Seems like you're making the case for the Django (http://www.djangoproject.com) framework.

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.

One of the problem's we've had on our site with too many content types is that a lot of our views filter nodes by content type to separate things like authors and issues from content and so every time we add a new one, we have to go back to those nodes and add the new type to the filter in the view. Plus the structure of most of our content types is similar, or close enough that much of the template is the same for all of them. Most of the code in each template is repeated from one to the next. I really wish there was some kind of content type hierarchy or inheritance so those types of properties could be passed on to "children" content types. What have you done about this problem?

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.

Steve, Are you using panels module at all to customize/override specific node types? Just learned how to due panels node override in D6 this week. Seems to be a good way to "package" content.

So the No. 1 reason for not changing (and using Python/Django) is a legacy investment in PHP/Drupal? See: http://www.yelvington.com/blogs/change http://www.yelvington.com/blogs/innovation http://www.yelvington.com/blogs/disruption If you've seen Adrian Holovaty's impressive demos, I'd assume you're familiar with why he (and his team) abandoned PHP.

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.

> Anonymous: You're assuming the wrong problem. We're not trying > to make programmers happy. Could you elaborate? Your answer seems to suggest that if it comes to a choice of happy users or happy programmers, then it's hard cheese for the programmers? That seems kinda harsh. Or is it more just a case of benign neglect of programmer well-being? What consideration is/was given to programmer opinion?

I like it. Great post man... http://www.socialnews.org

Good post, Steve. My own experience, like yours, suggests that thirty content types is perfectly reasonable. All you need is a heterogeneous site, with maybe organic groups, and feed consumption like you mention, and you've got a good argument for at least two dozen types. (I've got some work in the pipeline at the moment for a module to categorize content types, so you get a saner admin/content/types page when you've got dozens of content types, something more readable and usable. Only on D5 but looks like that's what you're using. I've just got a blog post up about it, so let me know if you're interested.) As a Drupal and Django fan, I definitely think there are times when a RAD framework just doesn't give your content the sort of attention that a "proper" CMS provides. You have to bootstrap a lot of detail about workflows, publishing status etc. that are implicit in Drupal's core concepts of nodes, comments etc. Then, when you've done that, the MVC API that a RAD framework gives you can be too loose---too dangerous, from the point of view of production and fidelity---to ensure that those concepts continue to "get the respect they deserve" between editing and presenting to the user. Finally, to Anonymous:
Your answer seems to suggest that if it comes to a choice of happy users or happy programmers, then it's hard cheese for the programmers? That seems kinda harsh.
If it really comes to that binary choice---which isn't the case mentioned here anyway---then the user must always win, and for an open-source project to acquire the quantity and demographic spread of users that Drupal (or Ubuntu, to take a non-CMS example) is aiming for, then there must be a movement to champion the user's preference above the developer's; hence e.g. d7ux. Besides, Drupal's APIs provide a neat framework to build in. Personally, I quite enjoy the light-touch leverage you can get with a nicely-placed hook_form_alter and #submit. But then I don't have a TV, which probably explains a lot.

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.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

Well i can say that i never liked drupal that much as i like Wordpressdue to its hook model. its not transparent ... -- finasteride online

The framework in a box approach is not a wise design for large sites. Many of those applications are bloated with code attached to other code that might not be needed but can't be removed without breaking it, and not designed for heavy traffic. It's clearly better to have a designer and programmer to produce a CMS from scratch in the preferred language (e.g., ASP, PHP, .NET). It creates a lighter load on the server, saves money, and is easy to edit.