All of the entry scripts include the same important file: config.php. This is the only file in Moodle that must be included by specifying the exact literal path. This file performs a number of initial parameter assignments in the global $CFG variable. This provides the minimal amount of information to run the rest of the system; among this information are the database, web URL, script directory, and data storage directory definitions.

Lastly, and most importantly, config.php includes /lib/setup.php.

config.php performs some basic, important variable assignment, whereas setup.php performs all of the initial program execution required to complete the execution environment setup. This includes defining several other important global variables, including $SESSION, $COURSE, $THEME, and $db.

Next, it sets up and connects your database according to the settings defined in config.php. Moodle uses the open source ADOdb libraries to manage database functions. These functions are loaded through the inclusion of /lib/adodb/adodb.inc.php.

Next, some critical library files are included that will be used by pretty much every other function in Moodle. These libraries include the functions required to manage multibyte strings, HTML output, Moodle data, access controls, events, groups, and general purpose Moodle and PEAR libraries.

The remainder of the file sets up some other critical global variables, loads configuration variables from the database, sets up caching, sessions, environment variables, themes, language, and locales.

After including config.php, our script includes some other library files:

require_once('lib.php');
require_once($CFG->libdir.'/blocklib.php');
...

This uses the PHP construct require_once, in case any of the files were included elsewhere first. Any file not located in the same directory is fully specified using directory definitions defined in config.php. You will notice lib.php has no directory specification, as it is located in the same directory as view.php. Likewise, the remaining files have full paths using directory definitions set up by config.php. You will notice the use of $CFG->libdir and $CFG->dirroot. The first is the defined file path to the main library directory (usually the lib subdirectory of the Moodle file path), while the second is the defined Moodle file path. Next, our script checks for, and loads, any parameters that it expects to get from the URL:

$id = optional_param('id', 0, PARAM_INT);
$name = optional_param('name', '', PARAM_RAW);
...

It does this by using the Moodle optional_param function, which loads the specified variable with a named parameter value if one is present, or a default value if not. If the parameter is required for the script to work properly, then the function required_param should be used instead. Both of these functions validate the data based on the specified arguments, and will generate errors or warnings if something other than what was expected is passed in. This is critical to securing user input in case of any additions to Moodle. SeeChapter 10, Writing Secure Code for more information.

Next, our script loads the specific records that it needs from the database:

if (! ($course = get_record('course', 'id', $id)) ) {
error('Invalid course id');
}

This can be done with either a database call, as above, or a specific API call.

At this point, our script has enough information to check if the user has permissions to access its basic functions. This is done by loading contexts, checking the user login, and verifying capabilities:

preload_course_contexts($course->id);
if (!$context = get_context_instance(CONTEXT_COURSE, $course->id)) {
print_error('nocontext');
}
require_login($course);

Much of the capability verification is performed by the require_login function. It verifies that the user is logged in (if necessary—some courses may not require that) and redirects them to the login function if required. It also loads and checks specific capabilities, including whether or not the user has access to the course. It also verifies enrollment and redirects the user to the enrollment function if necessary.

Next, our script will perform the necessary programming required to carry out its functions. Once it has finished this, it will begin the display process. The main functions for display are the print_header and print_header_simple functions. The following script uses the print_header function from the PAGE object it set up:

$PAGE->print_header(get_string('course').': %fullname%', NULL, '', $bodytags);

This function starts the HTML output by writing the HTTP headers, the theme information, requested JavaScript files, and other header section information. Then it begins with the body section.

The body output is handled by the specific course format. Whatever format has been specified for the course in question in its settings, handles the body output. This is done as follows, by including the file format.php from the subdirectory of the format in question:

require($CFG->dirroot .'/course/format/'. $course->format .'/ format.php');

If the course used the topics format (for example), then the file would be /course/format/topics/format.php. This file handles the specific course page output, including the blocks and main content. It uses library functions found in /course/lib.php to output the section's content. Lastly, the script outputs the footer:

print_footer(NULL, $course);

This function closes the body and completes the output to the screen. In most cases, this will be the last function executed for a script.