What Would Drupal Do?

Here's a wacky idea - arbitrary attributes that can be assigned on an individual node basis.

Even wackier - a brokerage system to allow these attributes to be globally registered.

What do I mean, and what's the point?

Right now, developers do all sorts of strange things to coax desired behaviour out of Drupal. Consider the case of featured content. You want certain types of content to be "featured", and you want to perform certain types of actions for featured content that you don't want to perform for other content. Perhaps a graphic next to the title in a teaser view.

There are countless ways that a scenario like this gets tackled, three in particular which are most common.

The cloned node type:

Ok, so you create a new node type: Featured Story. It has a title and body, just like a story node. But we know it is different than a story or a page. We gave the node type a different name after all, and we will treat it differently, even if it is identical in every other way with a story or a page node.

In Drupal 4.7.x you do this with CCK, in Drupal 5 you can do it directly through the core installation. Great. So now at the theme level, you can add your image on nodes that match node->type 'featured article'.

It works well, and if you've done any amount of development with Drupal, you've probably used similar techniques. The support forums are full of people explaining to newcomers that it really isn't as tricky as it sounds. But it can quickly get unwieldly.

What if you have a node type of Review, and it occurs to you that some reviews should be featured as well?

Well, you could create another new node type - Featured Review. And what if down the road you realize that you need to feature some recipes? Well, another new node type Featured Recipe that is identical to your Recipe node type.

You go on and theme these nodes at the theme level, and on it goes. Everything that we might want to designate as "featured", we create a new node type for and a new template. Or we find a higher level at which to template and add in some cursory logic such as

But every time we think of a new type of content that might need to be featured, we are in the position of creating a cloned node type, tracking down our theme logic, and adding in a conditional to account for it. We could get very clever, of course, and parse the node->type string for the word "Featured" and if found, then add our image. That way we don't need to anticipate each node type in advance, or alter our theme logic, we simply create our cloned node type and off we go.

But it's still a pretty messy way to handle things. What are we really trying to do? We are simply trying to designate -- to communicate -- that this content is featured in a way that other content is not. The actual nodes are hardly different; in fact they are identical in everything but name. So we move on to a more sophisticated approach ....

CCK Fields:

We're all familiar with this. Rather than that nasty business of creating cloned node types, we'll add a CCK field to any of our node types that we might want to feature called "Featured" with a boolean value. To feature an article, we edit our node and set the "Featured" CCK field to true. At the theme level, we check if the node has a "Featured" CCK field that is set to true, and if so, we add our image.

Much nicer.

One of the drawbacks to this approach is that we can't feature "story" or "page" nodes in 4.7.x, because we can not add CCK fields to core defined node types. However, Drupal 5 does allow us to do so.

This approach works very well, except that we still must anticipate in advance each type of node that we may sometime in the future want to feature, create those node types with CCK (in 4.7), and add a CCK field to all of them. And what if there are other attributes we might want to arbitrarily associate with nodes? Say, "perishable" or "votable" or "private" or "commentable". We quickly end up in a scenario where we have to add a monster amount of CCK fields to each type of node and we greatly increase our workflow when creating content by having to iterate through each one and select the appropriate value.

Ah, but there's another approach.

Meta Taxonomy:

Glorious, flexible taxonomy. It can be used for so much. We can bend in to our will to perform all sorts of interesting functions that it was never designed for. (No wonder newbies find it so difficult to come to grips with -- for seemingly every conceivable development hurdle, there is a solution or three based on taxonomy)

Quick and dirty: we create a vocabulary called something appropriately vague like "Meta". To this vocabulary we add any of the attributes for which we might want to flag content as terms, without having to anticipate in advance what content that might be, or even what type of nodes that may be. So we add the terms "featured", "perishable", "votable", "allows_comments", and whatever else we may think of.

At the theme level, we make sure to not output any taxonomy terms that belong to our vocabulary "meta", but we act on the presence of those terms in appropriate ways. A story node has the term "featured" associated with it? Add the icon. It also has the term "votable" associated with it? Add a voting widget. What's this, it also has the "perishable" term associated with it? Unpublish it once it drops off the front page.

This is our cleanest solution so far, and taxonomy is well suited for it. It allows us to arbitrarily flag content and to act on it in appropriate ways. The trouble is, it simply isn't what taxonomy was designed to do. And we have to do some hacking to take that into account, such as suppressing some taxonomy output (our meta tags) while preserving and displaying others (the actual taxonomy tags used for categorization ... which is what taxonomy, ultimately, is about).

A Better Way?

So the question is: why don't we handle this explicitly through a mechanism by which we allow nodes to be flagged with appropriate attributes?

It would look and feel a lot like a streamlined, unhierarchical taxonomy -- but it would be decoupled from taxonomy proper. It could allow modules to register certain attributes that the module would then take into account.

Consider the vast amount of various voting and ranking modules. The responsible ones make use of Voting API, which is great. Now some automatically add a widget to every node. Some allow you to choose which types of nodes a voting widget will show up on. Some allow fine-grained control by which you can specify which individual nodes will or will not have a widget. Some are meant to be called explicitly at the theme level. Each has a different mechanism, and a different interface for interacting with that mechanism.

What if Voting API could simply register the attribute "VotingAPI: votable" at the time of installation. The various voting/ranking modules could then make use of attribute -- if a node has "votable" set, show the widget. You could swap in a different voting module, and it would perform consistantly.

A developer could add his or her own attribute terms through a taxonomy like admin page, and act on those accordingly.

I recognize that so far, I have been speaking of attributes, but talking more of something resembling a simple flag. Content is either tagged or not tagged. Attributes proper might look more like key/value pairs. In this way, content could still easily be flagged ("votable" == "TRUE") or have more complex behaviour ("perishable" == 2008-01-01) or ("allows_comments" == "anonymous,authenticated"). Futhermore, attributes could be integrated with Views and Actions, etc..

I'm interested in hearing feedback on this. Am I out to lunch? Perhaps some time off from Drupal development has left me not thinking in the Drupal Way. Maybe this has been discussed to death in the early days and dismissed for good reason, although I didn't have too much luck digging up conversation of the same in the drupal.org forums.

I'd see this starting its life, at least, as a contrib module and would be willing to do the grunt work if there is any interest.