This chapter is from the book
This chapter is from the book
This chapter is from the book
How Drupal Works
One of the great features of Drupal is that you do not need to write code to use it. However, it is useful to have a basic understanding of how Drupal manages its content, and that understanding can come from a superficial look at some of its code. Do not worry: There is little code in this section, and the most important message to take away is that Drupal's architecture is a sturdy one; it can be extended and modified by developers who have already been given specific places to customize Drupal. By using these customization structures, you can add significant new features to Drupal without jeopardizing the overall stability of its operations. You need have no fears about downloading additional modules from the Drupal website and installing them in your copy of Drupal.
When you download Drupal, you get a folder that you place on your web server. The most basic installation is to place its contents in the appropriate location—either the site's root or a subfolder. Note that it is the contents of the folder, not the folder itself, that you should place on your site. A subfolder can be used in the URL, as in www.northcountryconsulting.com/drupal1; alternatively, you can point a domain or subdomain to that folder.
Drupal's Bootstraps and Bottlenecks
The .htaccess file is located at the root level of the Drupal file structure. It is a simple set of Apache settings, the key one of which is that all requests coming into the directory in which Drupal is located are redirected to the index.php file in that directory. By the time they get to index.php, they have been reformatted, but all that is done behind the scenes by Drupal, so you do not have to worry about it.
The request is then routed into bootstrap.inc, a file in the includes folder of the working directory, as you can see in the following code. This means that every page request goes through the same logic that can check for various conditions.
define('DRUPAL_ROOT', getcwd());
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
$return = menu_execute_active_handler();
The $return variable contains the main section of the Drupal page to be returned to the user. After some error checking in index.php, the page is rendered with
print drupal_render_page($return);
Within that function, the page is rendered with this code:
function drupal_render_page($page) {
// Allow menu callbacks to return strings, or bare content arrays.
if (is_string($page) || empty($page['content'])){
$page = drupal_get_page($page);
}
// Modules alter the $page as needed. Blocks are populated into regions like
// 'left', 'footer', etc.
drupal_alter('page', $page);
return drupal_render($page);
}
This means that every request for a Drupal page goes through the same bottleneck where additional processing (such as modifying URLs) can take place, and every request to render a page goes through a similar bottleneck where different types of additional processing (such as placing blocks in regions of the page next to the main content) can be performed.
This is a common structure for modern web applications. Facebook applications, for example, consist of a Facebook frame that is created by Facebook independently of the app. The app is called by Facebook to return the center portion of the frame, and Facebook merges them together.
Using Hooks
Drupal's hooks are somewhat similar to bottlenecks. At specific moments, such as when content is about to be viewed, stored, or deleted, or when a user has just logged in or logged out, Drupal checks the modules (including ones you have downloaded and installed yourself) in case one wants to be involved. Thus, a module can modify the data to be displayed or it can do something to reflect the user's log in or log out. The implementation of these hooks is provided in the code for each module. (Not all hooks are implemented in all modules.) Each hook has its own syntax, and it is named with the module's name.
For example, the hook that is called when a node is about to be viewed is defined as shown in Table 2.1.
Table 2.1. Node View Hooks
|
Version |
Syntax |
Return Value |
|
6 |
hook_view($node, $teaser = FALSE, $page = FALSE) |
$node (possibly with changes) |
|
7 |
hook_node_view($node, $teaser) |
$node (possibly with changes) |
For a module called mymodule, the actual implementation in the module file would be mymodule_view or mymodule_node_view.
Unless you are writing your own module, do not worry about this, but it is useful to understand how Drupal manages its operations. If, for some reason, you are tempted to bypass Drupal's event-dispatching mechanism, you will break the hook structure. (Fortunately, it is not easy to bypass the event-dispatching mechanism.)
Drupal's File Structure
The whole functioning of Drupal depends on this combination of .htaccess and index.php. For it to function properly, the files must be in the right place. If you start to move them to improve on the file structure, you will break this robust structure.
The file structure does allow for several types of optimization within this structure, and you should consider them before you start your installation. Figure 2.9 shows the basic structure of a Drupal folder. You can see the index.php file; .htaccess is hidden. Two folders should draw your attention: modules and themes. These contain the files for modules and themes that either ship with Drupal or that you can download.
)
Figure 2.9 Review the Drupal file structure.
The temptation for many is to download modules and themes into the relevant folders. However, notice the sites folder in Figure 2.10; within it is an all folder, containing its own modules and themes folders. Those are the folders into which you should place your downloaded modules. That means that the main modules folder contains only the modules that were downloaded with Drupal itself. The ones you have added are in their own folder. This can make maintenance and updating much easier.
)
Figure 2.10 Use site-specific folders for modules and themes inside the sites folder.
Furthermore, you can add additional folders within the sites folder, each with its own modules and themes folders. That way, a single Drupal installation can serve several sites with several sets of themes and modules. All this works because of Drupal's runtime structure.