Home ›

How Drupal Works: An Architect's Overview—Notes

Submitted by Lin on Wed, 2010-04-28 12:10
in

Through the Lullabot podcasts, Jeff Eaton (and the other Lullabots) gave me my introduction to Drupal. I'm not sure how he packs his Drupal chatter with so much information and hilarity all at the same time, but the combination is definitely one of the things that got me hooked on Drupal. 

So reading quotes from this presentation as they popped up on Twitter is one of the things that made me most angry at the ash cloud. But it is now up online (!) thanks to the amazing DCSF organizers (double !).

Here are my notes. I've removed most of the funny (and got tired at the end), so you should really watch the real thing.

The worms eye-view of how a Drupal page is built can be really confusing, but this should help you grok the whole.
Although technically modules like User and Node are just modules, they are really the core of Drupal's architecture. Sites that you create with Drupal should be sites that thrive when using pieces of content that users create. Recognizing where your plan involves making Drupal into something its not actually good at is step 1.

About Drupal

  • Drupal is modular. That means if you take out all modules, then its just a set of APIs that don't do anything on their own.
  • Drupal is also event-driven. This fact can be masked to OO programmers by the fact that it is written in procedural PHP. But magically named PHP functions called hooks are the way of interacting with events as they are fired off. Your modules are listening for things to happen and doing something when those things happen. The idea of events and listeners using the hook system is fundamental.
  • Drupal is skinnable. Everything that a module generates that is going to be seen by an end user should be passed through the theme layer, which is separate from the plugin module that deal with data. This way, they can be transformed into XML, HTML, whatever, through the theme layer. Keeping in mind why drupal has this separation is important. The moment you think about creating a mobile version of your site, you will discover all the places where you forgot the hard coded HTML that you put in your module.
  • Drupal is organic. Drupal grows and evolves without a central roadmap. People complain about the way something works, and either someone else changes it for them or they try and change it themselves. It's worked pretty well, but there are downsides. For instance, there are three separate queue implementations that basically do the same thing.

API layer

Stuff that lives inside of the includes directory are the APIs, the core that make Drupal what it is. All modules sit on top of these services. The theme lives on top of that.

Menu API

Handles several key tasks. It does what other frameworks call routing. When a url is entered, it figures out which function it should use to build a page. It also magically builds convenient navigation menus and breadcrumb trails.

Database Abstraction

Sits there and allows us to make database queries against any database that someone has written a driver for. In Drupal 7, this gets easier since we're using PDO, a standard PHP library. 

Session Handling

Drupal tracks the use of all logged in users across multiple web hits. It allows you to swap out the storage mechanism for this.

Output Filtering

Handles scrubbing out nasty JavaScript and other filtering.

Caching

The ability to store the generated output for a page so Drupal doesn't have to generate it again for every page request.

Batch Processing

Multistage operations where you need to reload pages while chewing through thousands of nodes.

Module system

The fact that we can load modules from a folder and use the hook system to announce events for them.

Update system

Allows us to keep track of which schema pieces have fallen out of sync with the module code.

Unicode utilities

We can run lots of functions that ensure that localization doesn't do funky things with the text in the other language.
Other APIs
  • File storage
  • Locale & Language
  • Themeing (Rendering)
  • Forms & Processing
  • Image Manipulation
  • Email handling
  • XMLRPC

Page Request Process

  1. Someone fires a request to your webserver. They might get a cookie if they've already logged into the site.
  2. The server gets the request. It goes to .htaccess which says everything should go to index.php
  3. index.php loads the APIs and gets them ready to handle the request
  4. The Menu API which was loaded looks up the paths that different modules have registered that they handle.
  5. The module gets the request and fires hooks to see whether any module wants to help while it's building the page.
  6. The module returns some info back to the menu system.
  7. If the everything looks good, it figures out which theme is active and hands off the raw data to the theme layer.
  8. That gets kicked back to Drupal.
  9. That gets kicked back to the web server, which kicks it back to the user.

Drupalisms

Hooks

The hook system is an event listener that was cobbled together out of the function_exists functionality of PHP. 

Info Arrays

Drupal uses giant nested arrays to pass information around. You can stick anything in arrays, so you have to look at the API docs to figure out the different structures of the arrays in the APIs.

Callbacks

In an array, you stick a PHP function name in specific places. When the array is being processed, the function will be called.

Renderables

Arrays created by Form API and Node. In Drupal 7, the entire structure of the page is in a renderable. It's XML as an array. If it doesn't have a hash sign in front, it is a nested element. If it does have a hash sign, it is a property of its parent element.

Alter Hooks

The payoff for all the crazy array stuff. Drupal asks if anyone wants to change these arrays before they get fully rendered. It allows you to customize the guts of how other modules work without messing with their code.