Joomla execution path work-through

When debugging issues or doing development in Joomla!, it ishelpful to understand the basic Joomla! Execution Path. The execution path is the list of function callsthat are made during each page request.  While thecalls will change from request to request (depending on querystring parameters, cookies, session information, etc), the basicpath is the same each time.  We will cover thebasics and provide information to help developers find informationfor their specific situation.

 

Almost all requests to Joomla! start with the index.php filefound in the root of the Joomla! installation. Administrator requests go to the.../administrator/index.php file, but are similarto front-end calls.  There are also some caseswhere certain pages can be called directly, but in most cases,index.php is the starting point.

 

.../index.php

The following code is a security measure and defines a variableother pages use to make sure no one calls them directly. All other php files that should not be calleddirectly in Joomla! should include a check for this variable at thetop of the file:

// Set flag that this is a parent file
define( '_JEXEC', 1 );

We then setup some other variables and include/require somefiles.  The PROFILER code is used if you haveDebug System turned On in the Global Configuration and is used toprint out debug information at the bottom of the page. We will see more calls like this throughout thefile and will ignore them:

define('JPATH_BASE', dirname(__FILE__) );
define( 'DS', DIRECTORY_SEPARATOR );
require_once ( JPATH_BASE .DS.'includes'.DS.'defines.php' );
require_once ( JPATH_BASE .DS.'includes'.DS.'framework.php' );
JDEBUG ? $_PROFILER->mark( 'afterLoad' ) : null;

Finally, we do some work and get the Joomla! JApplication objectand call it's initialise method:

$mainframe =& JFactory::getApplication('site');

$mainframe->initialise();

The online Joomla! API site is a great place to use as areference for looking up functions.  ThegetApplication function and initialise method can be foundhere:

http://api.joomla.org/Joomla-Framework/JFactory.html#getApplication

http://api.joomla.org/Joomla-Framework/Application/JApplication.html#initialise

 

The API lists the files associated with these two classes whichcan be found here:

.../libraries/joomla/factory.php

.../libraries/joomla/application/application.php

 

For now, we won't worry about the specifics of the JApplicationinitialise method.  If you want to open the fileand look at the code to see what it does, that is the best way tolearn.  For now, just know that it initialises theapplication. ;-)

 

Next, we import the system plugins and trigger theonAfterInitialise method on them:

JPluginHelper::importPlugin('system');
// trigger the onAfterInitialise events
JDEBUG ? $_PROFILER->mark('afterInitialise') : null;
$mainframe->triggerEvent('onAfterInitialise');

The triggerEvent method is another one that we will seefrequently but won't explain every time.  Thiscall tells Joomla! to go through each enabled plugin of a certaintype and call the event on it.  In this case, thisis calling the System plugin onAfterInitialise event.

 

Next, we call the route method:

$mainframe->route();

This is the description of what the route method does and is inthe application.php code:

function route()

 

Then we authorize that the user is allowed to see this menuitem:

// authorization
$Itemid = JRequest::getInt( 'Itemid');
$mainframe->authorize($Itemid);

Once we know the user is allowed, we dispatch the request to theappropriate component:

$option = JRequest::getCmd('option');
$mainframe->dispatch($option);

The dispatch method is a very important call. This is the entry point into the component thatis being requested.  Every request to Joomla! endsup going to a specific component and follows a similar path. For this example, let's assume we are requestingthe following URL:

/index.php?option=com_content&view=article&id=39&Itemid=37

 

This is telling Joomla! to route the request to the com_contentcomponent.  The Itemid query string variable tellsJoomla! which menu item this request is for (as used above whenauthorizing).  Most of the other query stringvariables are used in the component, but a lot of them (view,controller, task, etc) are used across most components.

 

Joomla! will then execute the following file for thecomponent:

.../components/com_content/content.php

For a component named com_somethingelse, Joomla! wouldexecute:

 

.../components/com_somethingelse/somethingelse.php

 

 

To see a full explanation of the execution path once inside acomponent, see the article Joomla! Component Execution PathWalkthrough.

 

Finally, we render out the resulting response to the user:

$mainframe->render();

// trigger the onAfterRender events
JDEBUG ? $_PROFILER->mark('afterRender') : null;
$mainframe->triggerEvent('onAfterRender');

echo JResponse::toString($mainframe->getCfg('gzip'));

The render method is another very important call. This call will tell the JDocument object torender itself and will result in the template and modules beingrendered.  This topic will also be covered inanother future article that will eventually be linked to fromhere.

 

And that is it.  Not terribly complicated andeasy to follow.

 

 

Other resources

PHP has wonderfully helpful functions called debug_backtrace anddebug_print_backtrace that will tell you the path PHP took to getto the code you are at:

http://php.net/manual/en/function.debug-backtrace.php

If you know you are getting to a certain place in the code butnot sure what path was taken, use these functions to help debug theissue.

 

PHP also has a wonderful function called print_r. While the print function can be used to print astring or number, it can't be used to easily print out an object. That is where print_r can be helpful:

http://php.net/manual/en/function.print-r.php