Serving a Request
Having a conceptual framework of what happens when a request is received by Drupal is helpful, so this section provides a quick walk-through. If you want to trace it yourself, use a good debugger, and start at index.php, which is where Drupal receives most of its requests. The sequence outlined in this section may seem complex for displaying a simple web page, but it is rife with flexibility.
The Web Server's Role
Drupal runs behind a web server, typically Apache. If the web server respects Drupal's .htaccess file, some PHP settings are initialized, and clean URLs are enabled. (Drupal supports clean URLs, that is, URLs that look like "http://example.com/foo/bar." A mod_rewrite rule in Drupal's .htaccess file translates the path to index.php?q=foo/bar. So internally, Drupal always deals with the same path, stored in the URL query parameter q, whether clean URLs are enabled or not. In this case, the internal path would be foo/bar. The internal path is also called the "Drupal path".) In alternate web servers, such as Microsoft IIS, clean URLs can be achieved using a Windows Internet Server Application Programming Interface (ISAPI) module such as ISAPI_Rewrite.
The Bootstrap Process
Drupal bootstraps itself on every request by going through a series of bootstrap phases.
Configuration
This phase populates Drupal's internal configuration array and establishes the base URL ($base_url) of the site. The settings.php file is parsed via include_once(), and any variable overriding established there is applied.
Early Page Cache
In situations requiring a high level of scalability, a caching system may need to be invoked before a database connection is even attempted. The early page cache phase lets you include (with include()) a PHP file containing a function called page_cache_fastpath(), which takes over and returns content to the browser. The early page cache is enabled by setting the page_cache_fastpath variable to TRUE, and the file to be included is defined by setting the cache_inc variable to the file's path.
Database
During the database phase, the type of database is determined, and an initial connection is made that will be used for database queries.
Access
Drupal allows the banning of hosts on a per-hostname/IP address basis. In the access phase, a quick check is made to see if the request is coming from a banned host; if so, access is denied.
Session
Drupal takes advantage of PHP's built-in session handling but overrides some of the handlers with its own to implement database-backed session handling. Sessions are initialized or reestablished in the session phase.
Late Page Cache
In the late page cache phase, Drupal loads enough supporting code to determine whether or not to serve a page from the page cache. This includes merging settings from the database into the array that was created during the configuration phase and loading or parsing module code. If the session indicates that the request was issued by an anonymous user and page caching is enabled, the page is returned from the cache and execution stops.
Path
At the path phase, code that handles paths and path aliasing is loaded. This phase enables human-readable URLs to be resolved and handles internal Drupal path caching and lookups.
Full
This phase completes the bootstrap process by loading a library of common functions, theme support, and support for callback mapping, file handling, Unicode, PHP image toolkits, form creation and processing, automatically sortable tables, and result set paging. Drupal's custom error handler is set, the locale is set, and all enabled modules are loaded. Finally, Drupal fires the init hook, so that modules have an opportunity to be notified before official processing of the request begins.
Once Drupal has completed bootstrapping, all components of the framework are available. It is time to take the browser's request and hand it off to the PHP function that will handle it. The mapping between URLs and functions that handle them is accomplished using a callback registry that takes care of both URL mapping and access control. Modules register their callbacks using the menu hook. When Drupal has determined that there exists a callback to which the URL of the browser request is mapped and that the user has permission to access that callback, control is handed to the callback function.
Processing a Request
The callback function does whatever work is required to process and accumulate data needed to fulfill the request. For example, if a request for content such as "http://example.com/q=node/3" is received, the URL is mapped to the function node_page_view() in node.module. Further processing will retrieve the data for that node from the database and put it into a data structure. Then, it's time for theming.
Theming the Data
Theming involves transforming the data that has been retrieved, manipulated, or created into HTML. Drupal will use the theme the administrator has selected to give the web page the correct look and feel and hands over the resulting HTML to the web browser.
