How Drupal returns a page request

You hit a URL and Drupal gives you a page back. Magic! But perhaps you are wondering, what is Drupal doing under the hood? You know that putting it down to magic is not going to help you to create your own custom modules.

Drupal can be a complicated beast. So at this stage, I am not going to go into every little detail. Instead, we will take a look at a simple example to illustrate the main stages in the process.

Why is this important to understand?

Possessing a high level understanding of how Drupal responds to a request for a page is critical to understanding the bigger picture.

Firstly, when you create a Drupal module, you need to leverage the rest of Drupal. Modules are not standalone programs - they are a piece of the Drupal puzzle and Drupal will do a lot of work for you. But you need to understand what Drupal is doing first to be able to hook into it.

Secondly, when you create a module, something will probably go wrong. At least one piece of code won’t work as expected. Ahh.. a bug! When you debug code in a module, you need to know what the rest of Drupal is doing during the request lifecycle. It could be another module (or core) interacting with your module in an unexpected way that is causing the bug.

Thirdly, security. Drupal has a lot of security handling built in. Just like leveraging the power of Drupal for functionality, you need to leverage the security features of Drupal. Understanding the whole process will help you do just that.

Simple Example

This example is a simple blog page: http://befused.com/drupal/munich. This is a standard node page which is created using node/add/article. For the sake of simplicity, I have ignored caching. I will discuss how caching affects some of these steps in a future post.

Request a page on a Drupal site

Drupal answers a series of questions to figure out what to do. Let’s go through each of the main questions, one by one.

What do I do with the URL?

Initially, the web server receives the full URL - http://befused.com/drupal/munich. But Drupal only cares about the internal path, so it separates it from the domain name. This actually happens before it even reaches Drupal in the .htaccess file (.htaccess is an Apache configuration file that allows developers to override web server settings).

Separate domain from path

How do I get started?

Drupal then calls index.php, which lives in the root of a Drupal install. Everything happens via index.php. To get started, Drupal runs though a bootstrap process, which initialises the database, sets sessions, loads libraries and so on.

Drupal bootstrap

What is the path actually an alias?

Remember, Drupal has already separated the path from the domain? But drupal/munich is actually an alias and not the real Drupal internal path. The Drupal internal path is node/262. drupal/munich is mapped to node/262 in the database.

Get internal Drupal path from alias

Which module is responsible for the content?

The menu system maps the internal path to a call back function, which is normally responsible for getting content from the database. A lot of the business logic happens at this point.

Find callback function

Do other modules want to extend or alter?

Hooks fire, allowing other modules to hook into the process at various points. These modules can change the content returned, add business logic and extra functionality.

An example of this is adding comments to the blog post. The Node module provides a hook in point for other modules. The Comment module utilises this and attaches comments to nodes. This is where the true power of Drupal is, because modules can provide any number of hooks for other modules to implement.

Fire hooks

There could be hundreds of hooks implemented in modules, all able to alter the content.

How should the page look?

Theme system styles the content and the page for the browser. The theme system itself can call more hooks and change the content. The theme system is more than just the theme itself. It includes theme functions and templates at module level as well.

Theme the content

Drupal has answered all the questions, and is ready to return a fully formed HTML page to the browser, along with CSS and Javascript. The browser then renders the page for the user to consume.

Our page

Summary

This was a high level explanation of how Drupal deals with a page request. There is a lot of detail at each stage, but it is important for you to understand the overall picture.

To summarise the process:

You request a page.

In turn, Drupal:

  • Separates the internal path from the full URL
  • Bootstraps and initialises the database, sessions etc
  • Maps the path to a callback function, which gets the primary content
  • Modules can hook into the process and extend functionality and alter the content
  • The Theme System generates the HTML and styles it.
  • Drupal returns a fully formed HTML page to the browser
  • The browser renders the HTML page for the user

My book, Master Drupal 7 Module Development, will dive deeper into this. In particular, writing custom modules that define paths and callbacks, and implementing and defining hooks.

Take a look at the attached PDF which illustrates the request lifecycle.

If you like this post, you would enjoy my weekly Drupal newsletter, where I send out tutorials on starting and getting better at Drupal development. You can sign up in the box below, where you will receive a free 7 day Starting Drupal Dev course, followed on with the weekly newsletter.

To scale the Drupal development learning curve faster, check out my book Master Drupal Development. It will help you master module development faster to become a fully fledged Drupal developer.

File: 
AttachmentSize
PDF icon request_lifecycle.pdf31.44 KB

If you liked this, you'll love my book, Master Drupal Module Development.

"..the must have drupal developers book"


Feeling stuck with Drupal 8 module dev?

Get the free 7 lesson course that will help you get started today without feeling overwhelmed.

  • Create Drupal modules with just a few commands using the Drupal Console
  • Create custom pages
  • Create custom blocks
  • Create admin forms
  • Demystify routers and controllers
  • Bonus material

Find out more


Comments

Hey Blair
nice description. Although I knew most of it, It's good to see it in such a clear analysis. You seem to have a talent for describing complex situations.

Now if you could do the same thing for the page redering process? content builder, page pre process, hook page alter, .tpl.php etc.

That would be fantastic.

Regards
Christophe

Blair Wadman's picture

Hi Christophe,

Good idea. I will do that! Thanks for your comment.

Cheers,
Blair

Very well explained. Would be great if you could go in more detail especially including the hooks and theme functions and explain the order of execution of those in a simple graph.

Blair Wadman's picture

Thanks Asif. Good idea re the graph, I'll see what I can do!

This was a great explanation and very helpful. My only comment is hurry up and get the book written! I want to read more from you.

Blair Wadman's picture

Thanks Lanette. The alpha version of the book will be out very soon (hopefully this week!)

in fact I have found this question or a very similar one in a job interview :-D.

Best regards

Awesome, I think it's important to know HOW the software you use actually works.

Well written and gives high level of drupal flow. Thanks for this article.

Really damn good clearification.

Thanks

Awesome Articles

Add new comment