Skip to content

Application

Jump to bottom
Nuno Luciano edited this page Mar 28, 2025 · 5 revisions

XOOPSCube

Web Application Platform

index.php

Summary of the key points from the index.php file and the mainfile.php file:

  1. The index.php file is the entry point for the XoopsCube application. It requires the header.php file and sets up some global options using the $xoopsOption array.
  2. It then calls a delegate event, 'Legacypage.Top.Access', which allows other modules to modify the page content before it is rendered.
  3. Finally, it includes the footer.php file and outputs the page content using XCube's rendering engine.

The index.php file is responsible for bootstrapping the application by requiring the necessary files and calling an event to modify the page content before rendering. It also sets up some global options using the $xoopsOption array and outputs the page content using XCube's rendering engine.

The $xoopsOption array and the delegate event 'Legacypage.Top.Access' are key components of your XoopsCube application. Here's a summary of what each of them does:

  1. The $xoopsOption array is used to store various configuration options for the application. It contains information such as whether or not to display blocks, whether or not to show system messages, and other settings that affect the behavior of the application.
  2. The delegate event 'Legacypage.Top.Access' is called at the beginning of the index.php file to allow other modules to modify the page content before it is rendered. This can be useful for adding custom blocks or modifying system messages, among other things.

Note

You should focus on working with the $xoopsOption array and the delegate event 'Legacypage.Top.Access' when refactoring your XoopsCube application and fixing deprecated warnings and bugs.

mainfile.php

Summary of the key points from the mainfile.php file:

  1. This file is used to set up the XoopsCube environment by defining various configuration options using predefined constants and including necessary files.
  2. It sets the physical path, virtual path, database type, table prefix, salt, database hostname, username, password, and database name for the application.
  3. If a trusted path is specified in the XOOPS_TRUST_PATH constant, it includes the autoload file from that directory to ensure compatibility with Composer vendor autoloader.
  4. It then checks if the main XOOPS directory path and the trusted path are provided using the XOOPS_ROOT_PATH and XOOPS_TRUST_PATH constants, respectively. If they are not provided, it includes the precheck file from the protector module to perform some initial checks.
  5. After that, it includes the cubecore_init.php file to initialize the XoopsCube root object and the controller class. It also checks if $xoopsOption['nocommon'] is set or if the constant _LEGACY_PREVENT_EXEC_COMMON_ is defined before including the common.php file to execute common module process subset.
  6. Finally, it includes the postcheck file from the protector module to perform some final checks before the XoopsCube application can proceed.

Warning

The mainfile.php file sets up the XoopsCube environment by defining various configuration options using predefined constants and including necessary files. It also checks for the presence of the main XOOPS directory path and the trusted path, and includes the necessary files to initialize the application environment.

Cube Core Initialization

Summary of the key points from the cubecore_init.php file:

  1. This file initializes the XoopsCube framework by including necessary files and setting up the main controller using the XCube_Root class.
  2. It first checks if the XOOPS_MAINFILE_INCLUDED constant is defined, which indicates that mainfile.php has been included and sets up the XoopsCube environment. If not, it exits with an error message.
  3. It then checks if the XOOPS_TRUST_PATH constant is defined, which points to the trusted directory for Composer vendor autoloader. If not, it displays an error message and exits.
  4. After that, it defines two constants XOOPS_CUBE_LEGACY and LEGACY_BASE_VERSION to indicate that this is a XoopsCube system and provide version information for module developers.
  5. It then includes the necessary files for XCube core initialization: XCube_Root.class.php, XCube_Controller.class.php, and IniHandler.class.php.
  6. The script defines five file paths related to site configuration using constants: XCUBE_SITE_SETTING_FILE, XCUBE_SITE_CUSTOM_FILE, XCUBE_SITE_CUSTOM_FILE_SALT, XCUBE_SITE_DIST_FILE, and the file path for CorePack custom settings.
  7. Finally, it initializes the XoopsCube root object using XCube_Root::getSingleton() and calls the loadSiteConfig method to load site configuration files from the trusted directory. The method takes four parameters: the default setting file, the dist file (for CorePack), and the custom setting file and its salted version. The setupController method is then called to set up the main controller for the XoopsCube application.

Important

The cubecore_init.php file initializes the XoopsCube framework by including necessary files and setting up the main controller using the XCube_Root class. It also defines constants and file paths related to site configuration.

//
// XCube Core
//
require_once XOOPS_ROOT_PATH . '/core/XCube_Root.class.php';
require_once XOOPS_ROOT_PATH . '/core/XCube_Controller.class.php';
require_once XOOPS_ROOT_PATH . '/core/libs/IniHandler.class.php';

//
// IniHandler - default site, custom and distribution settings
//
define('XCUBE_SITE_SETTING_FILE', XOOPS_TRUST_PATH . '/settings/site_default.ini');
define('XCUBE_SITE_CUSTOM_FILE', XOOPS_TRUST_PATH . '/settings/site_custom.ini');
define('XCUBE_SITE_DIST_FILE', XOOPS_TRUST_PATH . '/settings/site_default.dist.ini'); // for CorePack
define('XCUBE_SITE_CUSTOM_FILE_SALT', XOOPS_TRUST_PATH . '/settings/site_custom_' . XOOPS_SALT . '.ini');

//
// How does the system decide the main controller
//
$root=&XCube_Root::getSingleton();
// Added XCUBE_SITE_DIST_FILE for distribution CorePack
$root->loadSiteConfig(XCUBE_SITE_SETTING_FILE, XCUBE_SITE_DIST_FILE, XCUBE_SITE_CUSTOM_FILE, XCUBE_SITE_CUSTOM_FILE_SALT);
$root->setupController();

XCube Core

XCube Root Class

The XCube_Root class is a central class in the XCL framework, responsible for managing various aspects of the application. Here's a summary of its key methods:

  1. The constructor initializes several member variables like mSiteConfig, mController, etc., and sets up the root path ($root) if not provided.
  2. getConfig() retrieves a configuration value from the site configuration (SiteConfig), handling cases with multiple parameters.
  3. setupController() creates an instance of the controller based on the configuration settings and calls its prepare method.
  4. getController() returns the current controller object.
  5. Various setter and getter methods for managing language, delegate, service, render system, permission, text filter, role manager, context, and session objects.
  6. The _createInstance() is a private helper method that dynamically creates an instance of a class from a given path and name, handling cases with multiple parameters and special cases related to the root path and loading files.

XCube Controller Class

The XCube_Controller class is a base class for all controllers in the XCL framework. It provides various methods and properties to manage the lifecycle of the web application. Here's a summary of its key members:

  1. mExecute, mSetupTextFilter, mSetupUser: These are callable objects representing the main object, text filter setup method, and user setup method respectively.
  2. _mFilterChain: An array to store action filters added to the controller.
  3. _mLoadedFilterNames: A map to track which filter classes have already been loaded.
  4. addActionFilter(): Adds an ActionFilter instance to the internal filter chain.
  5. _setupFilterChain(), _processFilter(), _processPreBlockFilter(), _processPostFilter(), _setupBlock(), _processBlock(): These methods are responsible for setting up and processing the action filters, blocks, and other aspects of the controller lifecycle.
  6. _processPreload( $path ): A utility method to load files from a given path, instantiate sub-class objects, and add them to the filter chain.
  7. Other protected methods for creating and setting up various components like delegate manager, service manager, permission manager, role manager, context, and session.

XCube_IniHandler

The XCube_IniHandler class is a simple INI file parser that provides a convenient way to read and manipulate INI files in PHP. It reads an INI file into an array, allowing you to easily access individual values or sections of the configuration data.

Here's a breakdown of the class:

  1. The constructor takes two parameters: $filePath, which is the path to the INI file to be loaded, and $section, which determines whether the INI file should be treated as having sections. If $section is true, each section in the INI file will be stored as a key in an associative array under its corresponding section name.
  2. The _loadIni() method reads the INI file and populates the internal configuration array with key-value pairs or sections. It uses regular expressions to identify comment lines, empty lines, and sections. Each line that isn't a comment or an empty line is treated as either a key-value pair or a section header.
  3. The getConfig() method retrieves a specific value from the configuration array based on the provided key and optional section name. If sections are enabled and no section name is given, it will default to retrieving values from the first section in the INI file.
  4. The getSectionConfig() method retrieves all the key-value pairs for a given section. If sections are not enabled, this method returns null.
  5. The getAllConfig() method returns the entire configuration array.

Overall, the XCube_IniHandler class provides a straightforward way to work with INI files in PHP applications that require configuration data.

XCube ActionFilter Class

The XCube_ActionFilter class is an abstract base class that defines the interface for action filters in the XCL framework. Action filters are responsible for modifying or enforcing certain rules during the initialization and execution of controllers. These filters can be used to perform authentication, authorization, input validation, logging, caching, and other tasks.

In XCL, an action filter is typically added to a controller using the addActionFilter() method. The XCube_Controller class manages an internal filter chain that is executed in order when the controller's filters are called.

The XCube_ActionFilter class has three abstract methods:

  1. preFilter(): This method is called at the very beginning of the controller initialization process, before any other action filters are executed.
  2. preBlockFilter(): This method is called when the controller's pre-block filter chain is executed. It can be used for tasks such as setting up template data or manipulating module options.
  3. postFilter(): This method is called at the end of the controller's post-filter chain, after all other action filters have been executed.

To create a custom action filter, you should extend the XCube_ActionFilter class and implement one or more of its abstract methods according to your specific requirements. For example:

class MyCustomFilter extends XCube_ActionFilter {
    public function preFilter() {
        // Custom logic before controller initialization
    }

    public function preBlockFilter() {
        // Custom logic during pre-block filter chain execution
    }

    public function postFilter() {
        // Custom logic after controller execution
    }
}

Then, you can add your custom filter to a controller using the addActionFilter() method:

$controller = new MyController();
$filter = new MyCustomFilter($controller);
$controller->addActionFilter($filter);
Clone this wiki locally