Introduction
Continuing thoughts on Drupal7 (and to be fair probably just an exercise in tidying up my brain and not much use to others) as a web development framework, I highlighted one of the major difficulties in part 1 in that you need to know a lot about Drupal before you can use it as a framework.
This post is a quick pointer if you come from a pure framework background and are trying to understand how Drupal 7 works.
Please don't think I dislike Drupal
Some people get uncomfortable by anything but bouncy happy optimism, personally if the glass is half full I want to know how easy is it to get a refill. I will post about why I invest so much time in Drupal later.
Where is the controller?
Typically you may start looking for some sort of controller, some PHP code somewhere, that tells you how urls are mapped and dealt with. In many frameworks you can follow this chain through the source code and then start experimenting (break it to understand it). There are many ways to describe it and disagreements over details and terminology but something akin to a Front Controller is what you may expect to find. Looking for something like this is not a good initial approach to take with Drupal 7
In Drupal page requests are handled by index.php which contains just the following code:
<?php
/**
* @file
* The PHP page that serves all page requests on a Drupal installation.
*
* The routines here dispatch control to the appropriate handler, which then
* prints the appropriate page.
*
* All Drupal code is released under the GNU General Public License.
* See COPYRIGHT.txt and LICENSE.txt.
*/
/**
* Root directory of Drupal installation.
*/
define('DRUPAL_ROOT', getcwd());
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
menu_execute_active_handler();
The controller here is menu_execute_active_handler() the problem if you want to follow what happens afterwards is that there is no extended object or xml configuration or any sort of centralized user generated code file that you can find to understand how urls are mapped to actions (page callback functions). This function is a core function that ultimately gets its appropriate page callback function to execute from a database table called menu_router obtains its content from the action, allows any interested modules to hook in and add further content and finally renders the content to the browser (by default). The menu_router table will be mostly populated from a disparate collection of modules (both core, contributed and custom), implementing hook_menu.
My advice if you are trying to quickly get a handle on Drupal as a framework, is to understand
hook_menu when I first started using Drupal the name put me off for a bit, something to do with menus? doesn't sound as important as it is but to quote from the documentation.
This hook enables modules to register paths in order to define how URL requests are handled.
more on hooks and the framework in a further post.
The following from DrupalconSF 2010 is a nice introduction to how content gets rendered in Drupal, Although bear in mind that some of the exact details may differ as it was quite early in Drupal 7 development.
If you want to see a built page just before it gets rendered then you can run a simple php script using drush scr to boostrap your application and run it.
<?php
$path = drupal_lookup_path('source','your/path');
echo "$path\n";
$page_result = menu_execute_active_handler($path,False);
print_r($page_result);
echo "\n";
What you will get should be the very large(usually) render array just before it is rendered in the to html (or possible something else). The
drupal_lookup_path is required as the path you see is probably not the path Drupal uses due to path aliases and clean urls.
