ExiteCMS v8 : Development Documentation

Startup Flow

This page will try to give you an insight into the processes that run under the hood of ExiteCMS when a page is requested:

1. index.php
   • ExiteCMS requires the use of the Apache module mod_rewrite, to redirect all URL requests to index.php in the DOCROOT of the website
   • Initial settings are defined, like error_reporting level and folder locations
   • Some application constants are defined (p.e. EXT, FCPATH, DOCROOT, ROOTPATH and APPPATH)
   • The ExiteCMS engine is started by loading the bootstrap controller

2. ExiteCMS startup
   • Load the ExiteCMS config class
     • Processes the config file exitecms.php
   • Load the Config class
     • Processes the config.php
   • Load the Hooks class
     • Enables the use of CI and ExiteCMS defined hooks
       Hooks can be used by modules to extend the functionality of the ExiteCMS core code without having to modify that code
   • Load the Input class
     • A check is done for COOKIE, GET and POST variables. GET's are discarded, and the contents of COOKIE and POST variables are sanitized to prevent hacking attempts
   • Load the URI class
     • This class with check and validate the URI.
       If not present or not valid, it makes sure the default controller is loaded
   • Load the Router class
     • Provides URI routing functionality
       NOTE: these CI functions aren't used by ExiteCMS at this moment
   • Load the Output class
     • Provides basic output functionality
       NOTE: we use the CI ouput methods are a wrapper around the ouput of the Theme class. This allows us to keep using CI functionality like p.e. the profiler, or even view files if we wanted to
   • Load the Language class
     • Loads the system language file. From this moment, errors can be displayed in the defined language
   • Database driver is initialized
     • From now on, database access is possible
   • Load the Session class
     • ExiteCMS doesn't use PHP's session mechanism, but CI's database based Session functions
       
     • The session class autoloads the Encrypt class, to be able to encrypt the session cookie
   • Load the Theme class
     • This makes the Smarty template engine available to ExiteCMS
   • Load the ExiteCMS class
     • The ExiteCMS class provides CMS core functionality to all modules
   • Load the Form_validation class
     • Provide functionality to modules for easy form validation and processing

ExiteCMS (and the startup process) loads the following helper functions:

• debug_helper - ExiteCMS extension?: provides the _debug() function to quickly dump variables
• is_valid_helper - ExiteCMS extension?: provides easy field validation functions
• date_helper - CI standard helper
• url_helper - CI standard helper
• string_helper - CI standard helper
• ajax_helper - ExiteCMS extension?: provides json_encode() and json_decode() for PHP4 and server-side ajax support functions
  
• language_helper - CI standard helper (extended to support language sections)

After this startup process is finished, control will be given to the bootstap controller. This controller is the hart of ExiteCMS, and performs the following functions:

• Create the cms_user object by loading the User class. When instantiated it will load the Authentication library, initializes it (load the configured authentication plugins), and creates the contents of the user object. This could be a valid user (if one is logged in) or a guest user object.
• Load the CI Benchmark library so we can use the benchmarking methods (if not already loaded)
• Load the CI Hooks library (if not already loaded). From this moment on we have hook support for plugins.
• Create the cms_site object by loading the Site class. When instantiated it will use the information in the $_SERVER[] array to determine from which site a page is being requested. If this fails, the bootstrap controller dispatches the not_found controller, and terminates.
• Create the cms_page object by loading the Page class. When instantiated it will use the URI information from the Router library to determine which page from the content tree is being requested. It uses the Tree class to traverse the content tree to find the page. This will never fail, unless the site found hasn't got a single page defined. If that is the case, the bootstrap controller dispatches the not_found controller, and terminates.
• The correct page processor controller is loaded to generate output from the cms_page object.
• Finally, the bootstrap loader performs cleanup, calls the post_bootstrap hook plugins, sets an 'execution end' mark, closes any open session, en terminates.