Drupal

Although Drupal is often described as a "content management system" (CMS) it is also a "content management framework" (CMF). In other words, unlike a typical CMS, it is geared more towards configurability and customization. Picture a range of measurement where one end of the scale is labeled “specific” and the other end “abstract”. On the “specific” end of the spectrum, you would have something whose form is very specialized because it’s meant for a specific purpose—like, say, a hammer. On the other end of the spectrum, you would have something much more abstracted, that is available to be configured any way you like, for a variety of purposes—like some wood and a chunk of steel. You could make a hammer, or any number of other things with the wood and steel.

Of course, while chunks of wood and steel are more “configurable” than a hammer, they aren’t terribly useful because few people have the specialized knowledge to work with such raw materials. Drupal’s purpose is to sit in the sweet spot between the two ends of the scale, and create a sort of “builder’s kit” made up of pre-designed components that can be used as-is or can be extensively reconfigured to suit your needs. Its design provides incredible flexibility while still allowing people who aren’t programmers to make powerful websites. This principle of manageable abstraction is important to understand, because it is a central concept to all things Drupal. When you understand why a measured amount of abstraction is valuable, you’ll begin to understand why this approach is such a strong argument for using Drupal.

The power of abstraction

Imagine you get yourself a shiny new toy truck and a matching toy boat, and as you are enjoying them, you find yourself thinking about how nice it would be if you had a toy that had certain “truck-like” qualities, and certain “boat-like” qualities. But, unfortunately, your truck and boat are firmly rooted at the “specific” end of the toy spectrum. They are what they are, you must enjoy them as-is.

Now, imagine that someone hands you a case full of neatly arranged little toy vehicle parts organized according to type. They explain that this “vehicle construction kit” will allow you to snap together whatever sort of toy vehicle you like, with the ability to choose different body types, varied cockpits, and multiple propulsion mechanisms—lots of jets, propellers, wheels, tank treads, etc. Now, your truck/boat dream can become a reality. And, as you look at all the shiny new bits, you realize that a truck/boat is just the beginning.

Many popular content management systems are focused on a fixed, particular way of approaching the task of managing a website—they tend toward the “specific” end of our spectrum. While they may use various plug-ins to extend that functionality, the plug-ins are often authored in the same manner—they are very fixed in their task-oriented approach to getting things done. Drupal, on the other hand, with this idea of abstraction embedded in its DNA, is intentionally generalized in its approach to doing things. For instance, instead of creating a fixed “news engine,” Drupal provides systems and tools that allow you to quickly assemble your own custom news engine and tweak it to do exactly what you like. But because these systems and methods are generalized in their approach, they don’t lock you into just news-related things—you can use them to make all sorts of other “engines” and functional widgets. This means that once you learn some of the key tools within the Drupal universe, you will realize that you can endlessly combine them to do all sorts of clever things you (and the Drupal system/plugin creators) may never have imagined before.

A concrete example might go something like this: Say you want to have a news engine that lets you post news articles on your site, and you want to be able to put a little widget on the homepage that shows blurbs for the five most recent news stories. Next, you decide that you want to keep track of recent blog posts, and put a running list of blurbs of the five most recent of those on the homepage as well. With a CMS whose paradigm is rooted more on the “specific” end of the spectrum, you’d likely look for a module that handled news, and had a feature that let you put blurbs on the homepage (not an uncommon thing). Next, you’d locate a module that would track the latest blog posts and put a list of those on the homepage (again, not unlikely to find such a thing). Each module would concentrate on tracking, managing and displaying the information it handles.

But, what happens when you have that brilliant middle-of-the-night idea, and want to blend these two functions by showing a list of blog posts about the latest news items, ordered by most-active-contributor first? If you’re using a “toy truck” CMS, you may be out of luck, or need to hire a developer to write you something custom. But with a CMF that’s built around the idea of abstraction, you can whip out your kit full of parts and knock this together pretty quickly. The advantage of an architecture like Drupal’s is that the generalization and standardization in how it does things means that building all sorts of clever, customized site functions is just a matter of snapping parts together. And, to return to our toy metaphor, we aren’t talking about those shabby, knobbed blocks that let you create only rough approximations of the things you want—Drupal’s flexibility is layered, and it gives you highly granular control over nearly every aspect of what you’re building.

Of course, this flexibility comes at a certain cost. While a toy truck is instantly understandable and ready to use without much thought, a modular vehicle construction kit will by nature require you to read the instruction manual first. Keep in mind, this is not about building from scratch, it’s about learning how to connect modules and systems that are already available to create articulate, customized websites.

Drupal has been intentionally kept flexible enough that its power, and the means of accomplishing certain tasks are not immediately evident to those unfamiliar with it. However, after investing a little time, you will find that learning how to do things the Drupal way opens up a whole new world of possibility you never knew existed outside of custom programming. You will likely leave your toy truck and boat in the closet gathering dust.

How Drupal does it

As explained above, Drupal’s power comes from its more abstracted approach to handling web content and functionality. People often think of a website as a collection of pages, with some functions (like a blog, or a news engine) thrown in to round it out. When they go to manage their site, they are thinking in terms of a tree-like hierarchy of pages that they will go in and edit.

Drupal, on the other hand, treats most content types as variations on the same concept: a node (more on these in a moment). Pages, blog posts and news items (some possible node types) are all stored in a common pool, and the sitemap (its information architecture) is an overlay that is designed separately by managing and editing navigation menus. It’s a lot like the separation you find in standards-compliant page coding—XHTML provides the meaningful structure of the information, while CSS arranges it for presentation. In Drupal, nodes hold the structured information pertaining to a blog post (such as title, content, author, date) or a news item (title, content, go-live date, take-down date), while the menuing system creates the sitemap as a separate layer. Other elements (node layout themes, and modules like Views and Panels) provide the onscreen display of node contents.

The beautiful thing about keeping these layers separate, is that it’s simple to provide completely remixed sitemaps for different user types just by serving them a different navigation menu based on their login information. Pages can be grouped differently, prioritized in a different order based on user needs, and various functions and content can be shown or hidden on a per-user-type basis. It just depends on the experience you want to create.

OK, so what exactly is a node? At its most basic, a node is a cluster of related bits of data. When you create a new blog post, you are actually creating a collection of things such as title, content, author link, creation date, etc. Some of these data points hold information that is displayed when the node is displayed. Others hold meta-data that describes important facts about the node (such as the category).

By keeping all nodes in one big “bucket” instead of segregating them out into separate systems, Drupal ensures that they are all built on the same foundation, and can be handled in the same way. This means that they can all be remixed with down-to-the-pixel control over how they are displayed, and their data points can be used and combined together to organize, search and relate nodes with other nodes. This flexibility makes for some powerful possibilities.

Again, because the idea of abstraction is built into the Drupal paradigm, instead of creating specialized solutions for each and every little thing someone might want to do, systems and methodologies have been built to handle more generalized tasks, and then threaded throughout the entire CMF. These more generalized ways of doing things mean that once you learn how to use a particular methodology, you can use it in all sorts of places, and begin to string things together in inventive new ways.

As an example, let’s go back to that idea of remixing a site based on what type of user a visitor is. This concept is threaded throughout Drupal, so not only do you get to customize the sitemap based on user type, but you can show or hide blocks (chunks of data usually set in a sidebar, often the result of some kind of output, like our previous top five news blurbs example), change the site skin, and even shift how node information is displayed and whether a user can comment on a particular node. All of this and more can be switched around on-the-fly based on how a visitor identifies herself.

And a note about comments: this is another illustration of Drupal’s generalized approach to things. Comments aren’t just part of the blog system, since there really isn’t a segregated “blog system.” Comments are their own thing, and the ability to leave comments can be “snapped onto” blog posts, news items, book pages (a sort of wiki-like environment) and all sorts of other node types—even ones you custom-create.