Be Circle: Freelance Drupal expertise. Playing full contact Drupal in Toronto.

This is the 6th installment of the Drupal 7 Line by Line series of articles.

Up to this point in the series I've covered index.php, the basics of the drupal_bootstrap function and have been working through Drupal's bootstrap phases. (Links to earlier articles in the series can be found at the end of this article).

In the last article I covered the Drupal database bootstrap. In that article I mentioned the following:

[when I wrote about] page cache bootstrap process I noted that unless your site is configured in a specific way, both the DRUPAL_BOOTSTRAP_DATABASE (phase 3) and DRUPAL_BOOTSTRAP_VARIABLES (phase 4) bootstrapping phases will be completed before the page cache (phase2) bootstrap process can itself finish. As a result, I am technically covering the database bootstrapping process out of order and am not literally following the line by line code execution of Drupal exactly. I hope you can forgive me.

Keeping that in mind, today I will cover phase 4 in the bootstrap process: DRUPAL_BOOTSTRAP_VARIABLES.

Welcome to the 5th installment of the Drupal 7 Line by Line series of articles.

In the first four installments I covered index.php, the basics of the drupal_bootstrap() function and the first two phases of the Drupal bootstrap process: DRUPAL_BOOTSTRAP_CONFIGURATION and DRUPAL_BOOTSTRAP_PAGE_CACHE. (There are links to those articles found at the bottom of this article if you want to catch up.)

In the previous article about the page cache bootstrap process I noted that unless your site is configured in a specific way, both the DRUPAL_BOOTSTRAP_DATABASE (phase 3) and DRUPAL_BOOTSTRAP_VARIABLES (phase 4) bootstrapping phases will be completed before the page cache (phase2) bootstrap process can itself finish. As a result, I am technically covering the database bootstrapping process out of order and am not literally following the line by line code execution of Drupal exactly. I hope you can forgive me.

_drupal_bootstrap_database()

The third Drupal bootstrap phase begins with a call to the _drupal_bootstrap_database() function.

The first few lines of this function can put to rest any argument that Drupal is an application development framework (like Zend framework, or CakePHP, or symfony). In its current state it simply isn't. Here, on virtually every page load, Drupal checks to see if it in an installation state.

Welcome to the fourth part of the Drupal 7 Line by Line series of articles.

In this series I've been going through the Drupal page load process by going through the code line by line. So far I've covered index.php, the logic of the drupal_bootstrap function and the first bootstrap phase. (see the links at the bottom of this article if you want to catch up).

Today I'm going to cover phase two of the bootstrap process. This is where things start to get a bit more interesting as we see how Drupal handles page caching and how it supports pluggable caching backends.

Phase two starts with a call to _drupal_bootstrap_page_cache() from the drupal_bootstrap function.

_drupal_bootstrap_page_cache()

The first thing that Drupal does is declare the global $user variable which is used throughout the page load to represent the $user which is requesting the page. At this point it is completely empty. In fact, at this stage Drupal has no idea who or what is requesting the page.

In this third part of the Line by Line series I'll take a look at the first phase of the bootstrap process: namely DRUPAL_BOOTSTRAP_CONFIGURATION.

In the first part of this series I looked at index.php. In the second part I continued through the workings of the drupal_bootstrap function.

Up until now I've been literally going through the code line by line. From this point on I'm going to be less literal and only occasionally do line by line analysis where I think a closer look might be interesting.

So lets jump back in where we left off. I'd just finished explaining that Drupal was aware that it needed to do a full bootstrap and it was just about to start the first phase of that process.

Drupal calls the function _drupal_bootstrap_configuration().

Error Handling

The very first thing that happens in the first phase of the bootstrap process is Drupal defines its own error handling functions. Up until this point if an error had occurred in the code php would have used its own error handling to report the problem. Luckily very few lines of code have been executed to this point.

This post isn't technically a part of my Line by Line series of posts, but I thought I would share an ulterior motive for starting to write the posts.

At a practical level it is about re-familiarizing myself and other with all the things that go on during a typical page load in Drupal. A lot of things have changed in Drupal 7 so this is a worthwhile exercise.

But a lot of things haven't changed. Some really fundamental things.

Part of what I'm doing is shining a flashlight in some dark corners of code and thinking about how they could be better or different. Before I can think about actually changing things I need to fully grok why things are the way they are and make sure changes are worthwhile and not just changes for the sake of change.

I'm not sure what will become of all this, but its a personal pet project I've been thinking about for a while and I decided to start acting on it.

This is the second part of my Drupal 7 Line by Line series. In the first part I walked through Drupal 7 index.php. As you recall there are only four lines of code and two function calls that display all the pages on your Drupal 7 site.

In this post I'll start walking through one of those functions: drupal_bootstrap(). If you recall from Part 1 I said this function is starts up (bootstraps) all of Drupal's mechanisms required to handle a page request. This is only part of the story and only half the truth. A more accurate description would be that it loads up only as much of Drupal's functionality a php script needs so that the php script can uses that functionality to do something.

When drupal_bootstrap is called from index.php it is passed a single argument: BOOTSTRAP_FULL. In order for index.php (a php script) to display a web page (what the script does) it needs Drupal to bootstrap all of its mechanisms (i.e. a full bootstrap).

Lets see what the phpDoc comment and function signature for drupal_bootstrap() have to say:
<?php
/**
* A string describing a phase of Drupal to load. Each phase adds to the
* previous one, so invoking a later phase automatically runs the earlier

This is the beginning of what I hope will be a series of posts that take you through a Drupal 7 page load line by line.

Introduction

Before we begin, I want to share a story. Its the story of how I accidentally (or rather incidentally) became a Drupal developer.

A few years back I decided to be my own boss. I'd been working as a web application developer for a few years and it was time for me to strike out on my own. One of the first things I needed to do after writing a business plan was to launch my own website - the modern day hanging of a shingle.

I had a basic set of website requirements common to many businesses. I needed a flexible web based system that only needed to be install once and decorated (themed) very infrequently. Once installed it should allow me to enter and organize content via a web interface. I needed to be able to have it up and running in a relatively short period of time and I needed it to cost next to nothing.

Based on my own requirements, I knew I was looking for a modestly featured open source CMS or content management system.

I researched the available open source products that were available at the time. I read feature lists and reviews and eventually narrowed my choices down to Mambo (then soon to be Joomla) and Drupal. I installed both. Then for whatever reason I uninstalled Mambo and kept Drupal 4.4.

Toronto will be holding its 3rd Drupal Camp on October 15th and 16th at the Toronto Reference Library on Yonge (near bloor). We've had dozens of volunteers preparing for months to make this the best Drupal Camp Toronto has seen.

World Class Speakers and Topics

There are three keynotes featuring Dries Buytaert (founder of the Drupal project and CTO at Acquia), Jeff Eaton (Lullabot) and Mark Brown (Microsoft).

Besides the those big names we've got dozens of session proposals by several other big names that will be finalized into a schedule on Tuesday October 12th. (You've still got time to vote for your favorite.) Some popular proposals so far include Drupal scalability, Drupal 7 theming and Accessibility in Drupal 7.

There will also be a common area for plenty of Birds of a Feather sessions throughout the two day event. You'll have opportunities to talk with fellow Drupalers and presenters about things that excite you most about Drupal.

Register Now

It has been entirely too long since I've posted anything on my blog. Blame the wonderful spring weather we've enjoyed in Toronto or the workload of late. However true those two things are, I shouldn't go this long without posting anything.

So, to ease myself into publishing again I bring you one of my twice yearly posts encouraging you to attend the next Drupalcon.

In case you haven't heard the next Drupalcon is August 23-27th 2010 in Copenhagen Denmark. Tickets are available NOW and only €249 until June 28th.

If you've never attended a Drupalcon you're missing out. If you've only attended a North American Drupalcon, I encourage you to go to Europe and enjoy an entirely different atmosphere. Either way this may be the Drupalcon to attend. The King of Denmark will be putting on one heck of a show and it may prove to be the most social Drupalcon ever (with technical and business aspects ever present).

Last year I won a Nissan Cube and part of what I said I would do if I won was to decorate it and drive it to the next Drupalcon wherever it may be in North America. As it turned out, that "wherever" was San Francisco.

So yesterday I set out on the road with Danielle and we started making our way across the continent. But instead of sticking to our original driving plan which had us arrive in Colorado some time early tomorrow, we managed to make it all the way to Denver today. A little over 2,400Km in a little over 24 hours.