FlightPath is a large system, with many components working together.  This page will attempt to give a broad overview of how the pieces fit together.

Like Drupal

First things first-- FlightPath is similar in code and style to the Drupal project (versions 6 and 7).  It was greatly inspired by Drupal's system of "hooks", as well as the way that its menu router worked, and custom modules.  If you are already familiar with Drupal, you will find adjusting to FP development relatively painless (though there are various important differences).

Core vs. Custom Code

FlightPath attempts to have a clear separation between code considered "core" and that considered "custom."  Core code is not meant to be edited directly.  Instead, when further customizations are needed, they should be made to the custom region of FP-- literally a directory called /custom/.  This also makes updating FP easier-- you just backup your /custom/ directory, which contains all of your local changes, modules, and themes-- and copy it to a fresh copy of the latest version of FP.

Modules

Functionality in FlightPath is extended through the use of modules.  They are literally PHP files which have been renamed to .module, and they are placed in their own directories under /modules (for core modules) and /custom/modules (for custom modules).  Most of FlightPath's UI is handled through modules.  For example, the tab which lets a user search for a student is part of the student_search module.  The entire administrative side of FlightPath is handled through the admin module.

If you wish to add or change any UI aspects of FlightPath (by adding a tab, or perhaps you need to create a function which runs on every page load), then you would do it in a custom module.  Think of custom modules as a way of adding your own PHP code to FlightPath.

Hooks

Part of module development, so-called "hooks" allow a module to declare to FP that it has a particular type of function, and that FP should evaluate that function.

For example, FP will execute every hook_init() function when each page loads.  If your module is named mymodule, and you needed something to run on each page load, you would create a function named mymodule_init() and place your code there.  Notice that "hook" got replaced with the name of your module.  In this way, FP can go through a long list of modules, each with a hook_init function.

There are actually lots of types of hooks you can implement in your custom module.  An example of a powerful one is hook_form_alter(&$form, $form_id).  This hook allows you to make modifications to most of the onscreen forms in FlightPath (and even in other modules) to add fields, remove fields, or add special handling which should happen with the form is submitted.

View the includes/hook.api.php for a list of the various hooks available to the FlightPath developer.

Overriding Core Modules

Another very handy technique for customizing FP is to override the core modules themselves.  This is done simply by copying the module you wish to make changes in to the /custom/modules folder.  On the Admin Console->Modules page, the module will declare that it is being overridden by a custom module.

This way you can make changes to core functionality in the UI.  For example, you may need to override the student_search module, if the way of searching and loading your school's students is different from the way FlightPath expects.