Request processing in Habari

From Habari Project

Jump to: navigation, search

This page will attempt to describe in general terms what happens when Habari receives a request from a user. The process is basically the same for visitors (anonymous or otherwise) and users (administrators or otherwise), but each will be explained in detail for your benefit.

For the purposes of this document, we will assume that a client somewhere on the internet is accessing an instance of Habari at


Set up

The client computer will initiate an HTTP request to The Habari instance on the server will accept the request. All requests begin in the same way. This section describes Habari's set up process.


Before Habari is ever invoked, the web server software (Apache, Lighttpd, IIS) will evaluate whether the incoming request is an actual file on the server's hard disk(s) or not. If the request is for a specific file that does actually exist, the web server software will deliver this file to the client, and Habari will not be involved. This happens when serving .css stylesheets, for example. This might also happen when serving media files (images, podcasts, etc).

If the client request is not for a specific file that exists on the server's hard disk(s), the web server software will pass the request on to the Habari index.php.

Version Check

The very first thing index.php does is to determine whether the version of PHP installed on the server is at least version 5.2.0 or above. This is the absolute bare minimum version of PHP that Habari will support.


Next, index.php sets a constant -- HABARI_PATH -- that will be used throughout the program. This constant contains the filesystem path to the index.php file. For example, if Habari is installed at /home/habari/public_html, then HABARI_PATH will contain /home/habari/public_html. The HABARI_PATH constant is used in many places throughout the Habari code.

Output Buffering

Once the constant has been set, Habari enables output buffering. This is a process to delay sending any data to the client until such time as the server is ready to do so. In the normal execution of a web site, content is delivered to the client directly from the server as it is read in by the server. With output buffering, content is held on the server until the script on the server specifically tells the server to send it to the client.


The next portion of the index.php defines a function, __autoload(), that represents one of the fundamental building blocks of Habari. Although it is defined here in index.php, it is not executed at this time. The __autoload() function automatically locates and loads any PHP class files that are referenced for use within Habari. This function looks for class files first in the Site classes directory, if it exists, and then in HABARI_PATH/system/classes. By using the __autoload() function, Habari is able to dynamically load class files as they are needed, without requiring the Habari developers to pre-define every single class file and its location.

Error Reporting

With the __autoload() function defined, Habari now sets PHP error reporting to "All". This step is primarily to aid server administrators by ensuring that sufficient diagnostic information is recorded in the web server error logs if something goes wrong. Without this, it is often difficult to know exactly where a problem has occurred, or why.


Next Habari invokes a function called revert_magic_quotes_gpc() inside the Utils class. Because the Utils class is not yet defined, the __autoload() function is triggered. __autoload() searches for a file named utils.php in one of several directories. Unless you have created your own utils.php file, Habari will load HABARI_PATH/system/classes/utils.php and execute the revert_magic_quotes_gpc() function therein. This function undoes "magic quotes". Habari does not rely on magic quotes in the same way that many other tools do.


With all of that set, Habari is finally ready to load the config.php file that specifies how to connect to the database. A single installation of the Habari source code can power many sites, so there are a number of places in which the config.php file might be found. The get_config_path() function in the Site class determines where the correct config.php file is for this invocation of Habari. Remember, the Site class will be automatically loaded by the __autoload() function!

If Habari is only being used for a single site -- say a personal blog -- then the config.php file should reside inside the HABARI_PATH directory. However, Habari has no immediate way of determining whether it is being used for one site or one hundred sites. get_config_path() does the following:

  • defines the path to the config.php as HABARI_PATH, by default
  • looks for the existence of any config.php files inside any sub-directories of HABARI_PATH/user/sites
    • if none are found, return the default path of HABARI_PATH
  • Compare the URL used to access Habari for this request with the directories in HABARI_PATH/user/sites, using the following formula:
    • strip off the protocol used to access the site. becomes //
    • replace all slashes with periods. So becomes
    • place any non-standard HTTP port at the beginning of the directory. So becomes
    • if a match exists between the URL used for this request and a directory, return that directory. For example, matches HABARI_PATH/user/sites/


If there is no config.php, or if it is incomplete, the Habari installation process will be invoked. If there is a valid config.php, Habari will attempt to connect to the database. If that fails, the installation process will be invoked.

Content Type

Habari next forcibly sets the content type to text/html;charset=utf-8.


Habari sets the locale, which governs the language used to display Habari-generated messages. The default locale is U.S. English.


Plugins are loaded next, and the very first plugin hook is triggered. Any plugins registered against the plugins_loaded hook will be executed. See Plugins for more information.


The controller ( C in MVC (model-view-controller) "[p]rocesses and responds to events, typically user actions, and may invoke changes on the model." The controller first examines the request (Controller::parse_request();). This compares the requested URL against the list of registered actions in the rewrite_rules database table. If a match is found, the action specified in the rule is invoked against the handler specified in the rule. For more information on rewrite rules, see the Rewrite Tutorial. The controller contains an array of handler_vars, which are set by HTTP POST and GET values passed to this request, as well as any values set by plugins. Execution is then passed to the appropriate handler, through Controller::dispatch_request(), which calls the act() function in the handler specified in the matched rewrite rule. Execution is different, depending on the handler being invoked and what action is sent to it. The following sections describe the workflow for different handlers.

End User Workflow

In the event that the requested URL is simply to a public page of the blog, that is for the normal case of a user viewing the site, the handler will be UserThemeHandler. UserThemeHandler evaluates the request (home page, single post view, date-based archive view, etc) and loads the proper theme template files. For information on how Habari chooses which template file to use, see Template File Hierarchy. The handler will place the handler_vars into the theme's global variable space. The template files are then delivered to the viewer.

Administrative Workflow

For requests to the administration section of Habari, those whose path begins with /admin the AdminHandler will be invoked.

Authentication and Authorisation

Only users with administration privileges can access pages under /admin, so the first thing that AdminHandler does is check if the user is logged in, and if not redirects them to the login page. The user's privileges are then checked, and if they do not have administrative access an error message is displayed.

Routing the request

Once the user is authenticated and authorised, control is passed to AdminHandler->act_admin() which decides where the request should be routed based on the HTTP method used (GET or POST) and the page requested (the portion of the URL following /admin) to the appropriate function in AdminHandler. For example, a GET request to /admin/publish will be sent to AdminHandler->get_publish(), and the handler will prepare the publish page for display.

Administration Output

The administration section has its own theme, located in HABARI_PATH/system/admin. Each of the functions in AdminHandler specify which template should be used as their output, which is then output in the same way as any other theme.

Flush Output

The very last thing that index.php does is to flush the output buffer. Any output that has been prepared is finally sent to the browser.

Other Development Pages · Developer Introduction
Personal tools