Drupal 6 Bootstrap Process

When investigating a recent rash of spam user registration on my site I began looking through Drupal core to gain a better understanding of its inner workings and how modules could be used to guard against these nuisances. Like every journey there is a beginning, and for me it all started with index.php.

This is not a very big file, but it plays a vital role because access to content on any Drupal site (via HTTP GET or POST commands) is all directed to this one file. It starts off simply enough by including a bootstrap PHP file (bootstrap.inc). This file in turn defines several constants referenced throughout the Drupal code base as well as several core utility functions. Then magic begins The drupal-bootstrap function is called with the constant DRUPAL_BOOTSTRAP_FULL as argument (the function and constant previously defined by the afore-mentioend include file). This function serves to execute a series of phases in order to process all requests coming to the server. How many phases are executed depends on the argument given to the function. In the case of the index.php, the highest phase is used. The drupal_bootstrap function executes every phase in turn from low to high until it reaches the one it was invoked with. The order and names of these phases (as defined by the constants) are shown below.

This series of articles will focus on each of these phases and attempt to explain what's going on in more detail.

PHASE1 - DRUPAL_BOOTSTRAP_CONFIGURATION

This first phase is fairly straightfoward and as its name suggests it will initialize system configuration. However, before doing so it calls drupal_unset_globals() to unset all disallowed global variables. This is essentially everything except the superglobals _ENV, _GET, _POST, _COOKIE, _FILES, _SERVER, _REQUEST, and _GLOBALS. Starting from PHP 4.2.0 the automatic registration of globals was deprecated as it was deemed to cause potential vulnerabilities.

The next step in the phase is to create a timer to track the start of the processing for the page of content being requested.

The final step is the invocation of the conf_init() function, which is used to load the system configuration and set various global variables (eg. base URL, database URL, path, etc...). The following are the steps taken by the conf_init() function:

• validate the HTTP_HOST header sent by the client setting it to '' (empty string) if older browser (pre HTTP/1.1) did not send it
  
• checks for existence of settings.php file and if present includes it. It follows a specific sequence of directory traversal using both the HTTP HOST provided and the script's path to locate settings.php file. (eg. directory /sites/www.example.com would be searched before /sites/example.com). The Drupal API http://api.drupal.org/api/function/conf_path/6 has a more detailed example. If the initial directory traversal doesn't yield any results, it will default to using the /sites/default path
  
• sets the global database url variable $db_url (this will be required by subsequent bootstrap phases that require database access)
  
• sets the global base url variable $base_url (defined in settings.php or created automatically from _SERVER array)
  
• sets the global session name variable and cookie domain variable, $session_name and $cookie_domain respectively
  
• calls session_name() to set session name called 'SESS' with the md5 hash of the $session_name variable appended to it
  

The next article will focus on the DRUPAL BOOTSTRAP EARLY PAGE CACHE phase

< Drupal 6 Bootstrap ProcessupDRUPAL_BOOTSTRAP_EARLY_PAGE_CACHE >