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

• Q: Where are you? A: Select language.

Finally, Drupal delivers the content:

• Q: Which page? A: Serve up the page.