Drupal Is a Framework: Why Everyone Needs to Understand This

This is the sweet spot, the place where most (but not all) of the hook magic happens.

Hooks are little blocks of functionality, called functions, that contain PHP code. These blocks of code run when they are called upon. During the bootstrapping process, especially when the final "which page?" question is asked, hooks are called. Whenever an event happens in Drupal, like deleting a page, hooks are called. Inside those hooks, there is code that alters functionality, and it runs as soon as the hook is called. Almost anything you want Drupal to do has a hook doing it.

Drupal relies on naming conventions to call hooks when the time is right for them to run. While building the menu, Drupal looks for hooks with "_menu" in the name. When a page is deleted, hooks with the name "_delete" are called.

Drupal modules override existing hooks or add new ones. For example, if I want to change the way a form is displayed, I put the code for that change inside a function called mymodulename_form_alter. When the form's page is built, Drupal will look for any "_form_alter" function to see if there is more to do. I also can create new hooks in custom code that can be called by other hooks, mymodulename_myhook.

Hooks don't just govern behavior. The theme, which is the collection of files specifically dictating the site's look and feel, also includes hooks. The front end of a Drupal site (the presentation rather than the behavior) is not simply painted on; it relies on hooks as well, all being called when Drupal delivers a page.

Remember our three original questions: how long will this take, how much will that cost, and can my site do [insert cool new thing]? The answers, and whether something is easy (quick, cheap and already possible) or hard (time consuming, expensive and innovative), depend on hooks. "I would like my site to do X. Is that easy or hard?" The scale from easy to hard looks like this:

  • Drupal already does what you want it to do because the necessary hooks, with the necessary code, run by default.

  • Drupal provides an administrative interface for you to turn it on or change it.

  • A module or theme already has been written, calling or adding the hooks (with the necessary code inside them) that you need.

  • Custom code must be written (using or creating hooks and adding code to them). The time and effort required here varies widely, from three quickly written lines of code to months of programming, creating multiple contributable modules.

  • Custom database tables must be created. At this level of complexity, the code still will rely on hooks but begins to run outside of what Drupal does natively; therefore, it is (sometimes) more complex than adding code alone.

  • Necessary data comes from other Web sites, or your site's new feature requires communicating with other sites (for example, credit-card processing). The time and effort to do this also varies widely and can be as easy as adding a module (that already handles this communicating) or as hard as writing a separate application that runs when the appropriate hook is called. What your site will do with the data and the load it puts on the system greatly influences the complexity as well.

  • Your tasks can't run on page load, a special process has to be written to accomplish them. Sometimes, this is a quick addition (a simple cron job using hook_cron), and sometimes this is complicated. Often, this approach is used when data processing would slow page load down (or take down the site), so it is handled out of sync and saved (cached), serving the cached version when the page loads and the question is asked.

Does Drupal already include the necessary hooks running the necessary code and does it provide an admin interface to set up what you want to accomplish? Easy! Do you need to get mega-amounts of data from elsewhere, process and save it out of sync with page load, and create new database tables that interact with existing data? Hard!

Drupal core and many contributed modules are primarily designed to manage content, to power a CMS—which is why it is right to say, from one point of view, that Drupal is a CMS. Out of the box, users can create any content type imaginable—book reviews, recipes, scholarly paper submissions, press releases, blog posts and so on. An admin interface in Drupal 7 makes creating nodes (the foundational content type with a title and body) and adding fields of related data to them, like the author and publisher in a book review, a code-free task. Creating book reviews that include a cover image, author, publisher, publication date and a link to Powell's City of Books is quick. Adding a five-star rating to each review involves adding one contributed module and turning it on.

How hard it is to make the review look like the design depends on how much the design varies from the way Drupal presents the content to the page. If the author, publisher and so on will be displayed in the order it was created administratively and styled according to the site's general style guide, creating the look and feel involves adding some CSS to the theme's CSS file(s). Easy! But if the page will distribute the fields in a unique order or include custom behavior (like also displaying other books the user has rated), custom work needs to be done. Hooks in the modules and in the theme enable this work to happen, allowing the page load process to be interrupted and edited.

Ironically, the fact that Drupal enables the creation of a book review content type is also what makes it a framework. In the words of Larry Garfield, Drupal core contributor and member of the Drupal Association Advisory Board:

What Drupal is today is a tool for building a content management system for a variety of different needs. That's an important distinction for someone looking to build a Drupal site to understand. Drupal is not a CMS. It is the framework with which you build your own CMS, to your specifications, to suit your needs. It is a Content Management Framework.

Diving into the syntax of hooks does require programming knowledge and is, in my experience, where the discussion between developers and product owners should end. My developer cohorts and I discuss the technical aspects of implementing hooks: which to use, where to put them, when to call them, how to simplify the code they run, performance issues and caching plans, the decision to use contributed code or write my own. Once the decision to, for example, pull in feeds and display them is made, the "how" discussions begin. (Node.js anyone?) Communicating the issues that arise as the "how" is being implemented and making collaborative decisions with site owners is the fine art of managing development, the place where the conversations begin again. This process is made easier, every time, when everyone involved understands how Drupal works (framework!) and trusts the easy/hard assessments made by the development team.

Hooks create, define and override the Drupal tools used to build information architecture—associating content with other content and creating navigable structure. Nobody wants a Web site to spit out all of the content in one big blob. The primary tools to build information architecture are content types, menus, blocks, taxonomies and views.

  • Nodes, content types and fields give structure to the content. Fields (like author or publisher) make for easy content creation and visual continuity for the user.

  • Menus enable navigation by creating a structure of associations. Menus create a content geography and reveal the paths for exploring it without getting lost.

  • Blocks are boxes of content that can be associated with and displayed in a region, such as the sidebar or footer. These boxes can be filled with any kind of content: nodes and content types, menus, lists, text with markup, output like feeds or unique code-created lists like "most recommended". There are hooks, of course, to create, control, edit and override blocks, although most blocks are built administratively.

  • Taxonomies are lists of terms that can be associated with content. Most users are familiar with the idea of tagging, associating a blog post (for example) with a list of terms like "coding, biking, cooking or hiking" In Drupal, taxonomies can provide the foundation for more-complex use cases, but associating content is the most common.

  • The Views module is a list-maker, powered by a contributed module. Many complex tasks can be handled by Views, but at its most basic, it's the way to create a list of content in Drupal—for example, "all book reviews posted in the last three months". Views also can display content using associations, such as "all posts tagged with the taxonomy terms 'apple' and 'spinach', sorted alphabetically". The lists often are created using the Views administrative interface, but custom code can override the output (hooks!), and entire views can be created in code.

The Drupal framework is a kitchen where, yes, there already are tools in the drawer and ingredients in the pantry. But those tools and ingredients do not define the meals that can be made there. Teams of site owners, stakeholders, project managers, business-goal definers and developers can cook better meals together when Drupal is understood as a framework. Approaching Drupal as a CMS often means bending it to your will: "I want zucchini muffins like my mother used to make; do that." As a framework, Drupal encourages creating the best, most-elegant recipe within the scope of the endeavor: "Here's some zucchini, what can we do with this?"

Drupal's flexibility may make answering our three questions (how long, how much and can it be done) more time consuming. But in the end, the outcome is far more satisfying.


Diana Montalion Dupuis is a software developer, Web strategist, writer, trainer and hiker who doesn't spend enough time in the mountains. She lives in Austin, Texas, where it is too hot in the summer, and is VP of Engineering at Astonish Designs.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Joomla Installation Service

osdcsweb's picture

Thanks for sharing this article with us.

Hello, I have browsed most of

juliaware's picture

Hello, I have browsed most of your posts. This post is probably where I got the most useful information for my research. Thanks for posting, maybe we can see more on this. Are you aware of any other websites on this subject.Transmitter Enclosure FRP Panel

Architectural design is main

mathan's picture

Architectural design is main and important part of interior designing. Thanks for sharing this useful information. I welcome you for posting more updates
Interior Designers in Chennai


markswill's picture

Thanks for posting this informative article. I haven’t any word to appreciate this post.
High PR Backlink Builder

You should consider visiting

couponcode's picture

You should consider visiting McAfee Promo Code 2013 for information about McAfee

Joomla Template Design

osdcsweb's picture

Thanks for sharing thisarticle with us.Keep it up.

Joomla Installation Service

osdcsweb's picture

Thanks for sharing this article with us.

Ahh, the Koolaid.

Taran's picture

Ya know...

Once upon a time, Drupal was known as a CMS. It was marketed as a CMS. It even was a good CMS.

Lots of sites prior to Drupal 7 were built around this. I know. I've been using it since 2003, writing code, customizing, etc.

Now you can call Drupal 7 a framework. It's a freakishly weird definition that can be argued by drunk geeks everywhere - if I enjoyed the bar scene as much, I might join in - but the reality is that to most people who used Drupal prior to Drupal 7, they were forced into this framework crap.

A more thoughtful open source community would have forked the framework from the CMS.

Reply to comment | Linux Journal

WWE EXTREME RULES 2013 live stream's picture

Hey there just wanted to give you a quick heads up. The text in your content
seem to be running off the screen in Firefox.
I'm not sure if this is a format issue or something to do with web browser compatibility but I thought I'd post to let you know.
The style and design look great though! Hope
you get the issue resolved soon. Kudos

Reply to comment | Linux Journal

Treat vitiligo Around eyes's picture

It is perfect time to make some plans for the future and it is
time to be happy. I've read this post and if I could I want to suggest you some interesting things or tips. Maybe you can write next articles referring to this article. I want to read even more things about it!

Reply to comment | Linux Journal

what to say to women's picture

Hello, i believe that i noticed you visited my website so i got here to return
the prefer?.I'm attempting to find issues to enhance my web site!I guess its ok to make use of some of your ideas!!

Drupal is an Awesome CMS and a Crappy development framework

Lior Kesos's picture

After repeatably sinning by preaching the "applicative Drupal" pitch I now knowed I have erred and need to repent.
I've built numerous startups from the ground up using Drupal but I am now convince that is *not* the correct framework to build a serious startup.
It is simply to hard to complex you find your self wizzing by 90% of the project but then losing all of the headway because you can't figure out how to translate field collection or have crazy 4 relationship views that create SQL spawned by hell - just to develop it in the "Drupal Way (tm)"
I've tasted alternative frameworks like rails and node and mind boggling client MVC's like angularjs and I feel much more productive tailoring solutions using those tools (it's a common misconception to think they are not modular - rails or yeoman scaffolding is like drush support for cck".
I think it's the bash - perl -python path I've witnessed about a decade ago all of the perl devs where boasting perl but the main difference was that all of the python people where once perl devs and none have the perl devs have seriously tried python.
After you have 5000 concurrent users on a Drupal site trying to serve traffic with services you start to understand why serious startups would use node....

You say potato

Aidan Lister's picture

Sure, you can call it a framework ... the wikipedia definition fits, but it's not a useful distinction. Wordpress has hooks too, we're not calling that a framework now are we?

Besides, if you want to evaluate Drupal as a framework, it's an extremely poor one. It's horrendously bad at anything other than managing content which can be made to fit the node pattern. There's one or two examples of it doing other things (like Aegir), but these examples are limited and had other considerations.

Yes, Drupal's a very customisable CMS, but it's still a CMS. Calling it a framework is just playing word games. If you're curious to see the difference, spend some time with some actual frameworks like the excellent Symfony (Symfony being the framework D8 is built on) or Django (an excellent Python framework on top of which the Mezzanine CMS was built).

Drupal is a framework first

elvis2's picture

Drupal is a framework first then a cms... or whatever else you want it to be.

Thanks for comparing drupal with other cms'es.

Drupal is both, CMS and

Drupal Theme Garden's picture

Drupal is both, CMS and framework!

Reply to comment | Linux Journal

Melissa's picture

Ι likе thе helpful information
уou proviԁe in уоur агticles.
І'll bookmark your blog and check again here frequently. I am quite certain I'll leaгn plenty οf new stuff
right hеге! Beѕt of lucκ for
the neхt!

Nonsense. Of course it is a

Anonymous's picture

Nonsense. Of course it is a CMS. All cms's require custom programming to do what the CMS doesn't do by default. That's why there are a gazillion "modules", "plugins", and "widgets."

By your logic you can say that about any web app. "xxx cart isn't really a shopping cart, but it's the framework to allow you to build a shopping cart"

I disagree. The Aegir hosting

elvis2's picture

I disagree. The Aegir hosting platform is built off Drupal. Is the primary job to host content? Nope. It simply hosts sites, that host content...

Drupal can be a job server, a service bus, a file server, a notification system etc etc etc without ever hosting a single piece of "content".

Actually Drupal Commerce is a

Jonathan Brown 's picture

Actually Drupal Commerce is a framework that allows you to build a shopping cart.

OK, it's a framework

Marc's picture

Drupal may be a tool for building a CMS today, but I'd rather that there wasn't so much baggage along with it--anything that requires me to override this or that out of the box is just a pain.

Further I'd suggest that many of the new generation of CMSes are also frameworks but as an added bonus package a very loosely coupled CMS back end that is built on top of their own API (a beauty to behold), and overall take a lighter-weight approach that does not require overrides or coping with gobs of third-party markup the way Drupal does. I don't mean to bash Drupal, but this is why I don't use it.

Since it can also be said (and is said, all the time) that e.g. Joomla is a framework, I have personally stopped asking "is this CMS also a framework" when I evaluate a CMS. Instead I ask, "am I spending more time stripping logic out and writing ridiculously long selectors in my CSS or am I actually able to write the HTML I want, with the logic that I want, from the start? And does this apply to both back AND front ends?" This is crucial for small development teams. Larger teams may use Drupal but many also seem to seek out e.g. Codeigniter or Yii or Django. I believe that reflects some of the "I didn't write that markup and logic, so get it out of my way" thinking.

Frameworks and security

SeanW's picture

Having a framework is great but one must be careful to make use of its APIs and conventions for handling data, otherwise you leave yourself open to having your custom code exploited. I've been working a lot lately with finding compromised sites serving spam to Google and a good chunk of the ones I see are on a CMS like WordPress, Joomla, or Drupal.