Drupal Is a Framework: Why Everyone Needs to Understand This

Everyone planning and building Web solutions with Drupal benefits
from understanding what a "hook" is—and why Drupal is not a CMS.

One of the greatest challenges that Drupal adopters face, whether they are
new site owners or beginning developers, is figuring out what is easy and
what is hard to do with Drupal. As a developer, solution architect,
technical strategist and even as the friend who knows stuff about
Web sites, 60% of my discussions revolve around three questions: how long
will it take, how much will it cost, and can my site do [insert cool new
thing]?

Sometimes, these are easy questions to answer. Many content-related tasks
can be accomplished simply by logging in to Drupal, visiting the /admin
page and clicking on menu links until you land on the necessary
administration page.

More often though, there are complicated questions to answer. Some tasks can
be accomplished by adding contributed modules that easily "plug
in"
to Drupal core, as it comes "out of the box", and expand a
site's functionality. Contributed modules are created and shared by the
Drupal community and can be added to any Drupal site.

Some tasks require writing custom code, and new modules must be built.
Layers of potential functionality are involved in custom features. Some
features require communicating back and forth with other sites via an
application programming interface (API). Bigger Web sites often require the
creation of small applications that accomplish tasks in the background,
outside Drupal's usual workflow. In many cases, multiple solutions
exist, and choosing one involves giving something up to get something else.
As a developer or a stakeholder, finding the best solution that meets
business goals and stays in scope depends upon cooperative discussions.

That is where communication often breaks down. Developers are speaking one
language while site owners, project and account managers, stakeholders and
others involved in the decision-making process speak another language. When
people first learn about Drupal, their initiation often focuses on what a
node is, what blocks, content types and views are, and how to create
SEO-friendly URLs. These concepts are important, but they frequently fail to
answer the essential "how hard is this to do" question or provide
a strong foundation for collaborative planning of more complex
functionality. Everyone involved needs to understand that they can
architect a Drupal site that offers a more-sophisticated set of features
than a WordPress site, because Drupal is not a content management system
(CMS); it is a content management framework.

Conceptualizing Drupal as a framework does not require years of programming
experience; rather, it simply requires understanding what a
"hook"
is and finding out whether the one you need exists and already
is able to do the thing you want done.

To understand hooks, it's necessary to understand how dynamic Web
pages, delivered by Web applications, differ from static pages. Most
tech-savvy people take this knowledge for granted, especially Linux
aficionados and those whose first desktop computer had a flashing cursor at
a C: prompt. But many people don't know how Web sites do what they do.
(Why would they?) Here is how I explain the difference in layman's
terms.

In the olden days, static pages were single text documents containing
everything you saw on the page, except for images, in one text file. The
file included HTML tags describing the type of content being
displayed—for example, <p>
denotes a paragraph, and <h1> is a big headline. Browsers (which took
ten hours
to download) translated this markup and presented pages with a readable
structure at a Web address dictated by the filename. The document would be
uploaded to the server and saved in the Web site's primary folder. The
filename page.html then could be viewed using the browser at
yoursitename.com/page.html.

If you wanted to change the Web page's content, you edited that file. If you
wanted to change something in the header that appeared on all of the
site's pages, you had to edit every page. Whether linking content
together or displaying a similar sidebar, content was laid out individually
on each and every page by hand.

Nowadays, most sites are dynamic. Small programs, called Web applications,
are uploaded and stored on the server. Instead of delivering a static page
to view, the program runs when the browser lands on the page, applying
logic to the page creation process. This logic dictates how the page is
built each time a page is requested (also called "on page
load").
For example: the program gets the header, gets the main menu, gets the
page's unique content, gets the footer and delivers the whole page to
the browser. As a result, now there can be one editable header, one footer
and one menu shared among all Web pages.

What about the page's unique content? How does the application
"get" that? Imagine a spreadsheet where each row represents each
page's unique content. Dynamic Web sites store content in this way. They
use a database, which can be imagined as a collection of spreadsheets,
called tables. Each table, like a spreadsheet, has columns and rows. Each
row has a unique ID. When a page is displayed, the content associated with
that page—an article about container gardening, for example—is retrieved
from the database table and output to the page.

In Drupal's case, the programming language PHP supplies the logic and
MySQL provides the database. Usually, the operating system installed on the
server to power this process is Linux, and Apache is the software that
handles the requests for pages and delivers them once they are built. This
software bundle is called the LAMP stack.

Without static filenames like about.html, how does a dynamic Web site know
which row from the content table to display? Drupal, like other Web
applications, uses a query string to match the content to the page address.
Query strings look like this: ?q=1234, and they are attached to the end of the
URL—for example, yoursitename.com/?q=1234. Drupal uses a modified (no less
mystifying) address structure: yoursitename.com/node/1234. In both cases,
the unique ID, the row number of the page's content, is there: 1234.

Web pages displaying semantic URLs, like
yoursitename.com/growing-a-container-garden, have included logic that pairs
the unique ID with the words. But for each page, a unique ID still exists
and is associated with the content in a database table.

With the advent of dynamic Web applications, the continual development of
the programming languages and databases needed to drive them, and the
world's voracious need for more and more content-rich sites,
voilà—the Content Management System (CMS) was born. Drupal is a CMS insofar
as it is an application that saves content to a database and displays it to
a page using logic that is written into its core or added by programmers.
But Drupal is not (really) a CMS; it is a framework that does
"CMSey" stuff.
Drupal provides the structure for Web applications, far more complex than a
CMS, that do all the things Web sites can do: expand the functionality
(using contributed or custom code), communicate with other Web
applications, run applications written in PHP and other languages behind
the scenes, provide responsive pages or integrate front-end languages,
scale to handle large traffic numbers by making use of server technologies
and provide the foundation for other as-yet-unthought-of innovations.

Here's where the process gets ingenious. But, there is one more
conceptual step to take before it's clear that hard or easy depends on
hooks—bootstrapping. Again, this is a concept that may seem like common
knowledge to the tech-focused reader, but it can be tongue-twisting to explain. Here
is my layman's version, which is an oversimplification, but a deeper
understanding isn't a prerequisite to understanding hooks.

When a browser hits a Web page, Drupal asks a series of questions. The
question process is called bootstrapping. The questions (Q) trigger actions
(A).

Q: Who are you (generally) and what do you
want? A: Initialize and store
general info.

Q: Can I just give you a stored copy?
A: Serve cached data (content stored
in memory).

Q: Can I connect to the database?
A: Do so or die.

Q: Do I need anything from there to work?
A: Get it.

Q: Who are you (specifically)? A: Start a session.

Q: What are your requirements? A: Create
server/browser page headers (the
parameters for further relating).

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.

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 EnclosureFRP Panel

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.

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

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!

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

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

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.