Drupal line by line : part 5

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

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

In the previous article about the page cache bootstrap process Inoted that unless your site is configured in a specific way, boththe DRUPAL_BOOTSTRAP_DATABASE (phase 3) andDRUPAL_BOOTSTRAP_VARIABLES (phase 4) bootstrapping phases will becompleted before the page cache (phase2) bootstrap process canitself finish. As a result, I am technically covering the databasebootstrapping process out of order and am not literally followingthe line by line code execution of Drupal exactly. I hope you canforgive 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 anyargument that Drupal is an application development framework (likeZend framework, or CakePHP, or symfony). In its current state itsimply isn't. Here, on virtually every page load, Drupal checks tosee if it in an installation state.

<?php
<wbr></wbr> // Redirectthe user to the installation script if Drupal has not been
<wbr> // installed yet (i.e., if no $databases arrayhas been defined in the<br><wbr> // settings.php file) and we are not alreadyinstalling.<br><wbr></wbr></wbr></wbr> if(empty($GLOBALS['databases'])&& !drupal_installation_attempted()) {
<wbr><wbr><wbr>include_once</wbr></wbr></wbr> DRUPAL_ROOT. '/includes/install.inc';
<wbr><wbr><wbr></wbr></wbr></wbr>install_goto('install.php');
<wbr> }<br></wbr>?>

If Drupal decides that it is in an installation state it wouldload install.inc and redirect the request to install.php. With aspecific installer baked into its core Drupal has no separatedbetween the framework that its functionality is built on and theproduct that exposes that functionality. Please don't misunderstandmy point here. Drupal is a very flexible, extensible and developerfriendly CMS product. It is very much like a framework. It lookslike a duck and quacks like a duck, but it might be a swan or someother mixed metaphor.

But, I digress.

Drupal Testing System

Drupal 7 comes with a testing suite that allows developers towrite functional tests and run them to make sure that whatever theyare working on doesn't break the rest of their Drupal site. Part ofthat testing system is a fake 'user agent' / fake browser thatmakes page requests and makes the results available for testing inan automated way.

Here Drupal checks to see if the request is being made by thistesting user agent with a call to drupal_valid_test_ua(). If it is a request fromthe testing user agent Drupal overrides the database settingsdefined in settings.php. The reason for this is that if you arerunning tests (which require reading and writing of bogus test datato the database), you don't want to impact any real data on yoursite. So, if you are running tests they are run on a different setof tables.

The Database System

Finally, Drupal includes /database/database.inc.

<?php
<wbr></wbr> //Initialize the database system. Note that the connection
<wbr> // won't be initialized until it is actuallyrequested.<br><wbr></wbr></wbr> require_once DRUPAL_ROOT . '/includes/database/database.inc';
?>

This file contains the core of the new Drupal 7 databaseabstraction layer.

Here is a part of the code comments from database.inc:

<?php

?>

The workings of the new database abstraction layer is enoughmaterial for several articles. You may want to do some reading onyour own. I would suggest:
The main API documentation: http://api.drupal.org/api/group/database/7
Developing with the database API: http://drupal.org/developing/api/database

Autoloaders

Last but not least Drupal registers two autoloading functions.PHP provides a file autoloading mechanism so that if it encountersthe instantiation of a previously undefined Class or encounters theimplementation of a previously undefined Interface it can be toldwhere to look in the file system to load the file that contains theClass or Interface definition.

<?php
<wbr></wbr> // Registerautoload functions so that we can access classes andinterfaces.
<wbr> // The database autoload routine comes first sothat we can load the database<br><wbr> // system without hitting the database. That isespecially important during<br><wbr> // the install or upgrade process.<br><wbr></wbr></wbr></wbr></wbr> spl_autoload_register('drupal_autoload_class');
<wbr></wbr> spl_autoload_register('drupal_autoload_interface');
?>

These two lines tell php to use the drupal_autoload_class() and drupal_autoload_interface() functions forloading undefined classes and interfaces. Both of these functionsare actually a wrapper for the _registry_check_code() function.

The name of the function implies that Drupal now has a coderegistry. And indeed it does. What that means is that modules nowhave a way to tell Drupal where to find certain include files sothat when they are needed they can be 'lazy loaded'. To find outmore I suggest reading: Drupal's code registry.

Summary

DRUPAL_BOOTSTRAP_DATABASE is the third bootstrap phase. Itchecks to see if the site is currently in an installation state(rarely) and whether it is in a automated testing state (rarely).Most of the time it simply does two things: load database.inc andregister autoloader functions.

As always feel free to leave comments, corrections orquestions.