Introduce XoopsBaseConfig object

[geekwright]

Groundwork for easily switching XOOPS configuration, even inside the same directory structure. This will be useful in testing, sharing code between multiple instances, and more advanced configurations.

Right now, these changes just populate the object from the defines made in mainfile and secure.

[geekwright]

Note that if you apply this to an existing system, you need add the following to mainfile.php, near the end, just before the block that includes common.php. See mainfile.dist.php for reference.

if (!class_exists('XoopsBaseConfig', false)) {
    include __DIR__ . '/class/XoopsBaseConfig.php';
    XoopsBaseConfig::bootstrapTransition();
}

[redheadedrod]

Is this headed in the direction of multiple sites on same code?

Sorry been absent.. Still working out bugs in some projects and school has slowed me down.

Date: Tue, 27 Jan 2015 08:16:13 -0800
From: notifications@github.com
To: XoopsCore@noreply.github.com
Subject: Re: [XoopsCore] Introduce XoopsBaseConfig object (#241)

Merged #241.

—
Reply to this email directly or view it on GitHub.

                  =

[geekwright]

Multiple sites on same code is one of many use case that this could make easier.

This change is the first step in reducing the use of hard coded defines. In full use the XoopsBaseConfig object will be passed a configuration, by file path or array, that then becomes the source of the configuration data throughout the system. For example, instead of the define XOOPS_VAR_PATH, you have XoopsBaseConfig::get('var-path').

Once everything is converted, mainfile.php would look like this:

if (!class_exists('XoopsBaseConfig', false)) {
    include __DIR__ . '/class/XoopsBaseConfig.php';
    XoopsBaseConfig::getInstance('/path/to/configuration');
    if (!isset($xoopsOption["nocommon"]) && !empty(XoopsBaseConfig::get('root-path'))) {
        include XoopsBaseConfig::get('root-path')."/include/common.php";
    }
}

Looking at XOOPS, the library portion in xoops_lib holds the lions share of the code. You can share that using the traditional defines. But, by instantiating XoopsBaseConfig with the required configuration, you will be able jump straight into the xoops_lib without including mainfile. That make it much cleaner to test, as well as switch configurations.

Another issue with the defines is how unwieldy they become to change and adapt. For example, we have XOOPS_URL in mainfile, and XOOPS_COOKIE_DOMAIN in include/common. Looking at the whole environment, it would be nice to have a way to separate the URL for the assets directory, from the main XOOPS_URL, and set that URL and the cookie domain so that we don't send the cookies on each asset request. That reduces the load time for the static assets. Wow, now we need to add an asset-url, an asset-path, probably should move the cookie-domain up to mainfile, rewrite the mainfile.dist template and the installer. Or, we can add them to the configuration array. The defaults are easily synthesized, but once they exist, the level of control is immense.

Configuration by define was a useful technique, but as things mature, that technique becomes a boat anchor holding things back, making things less flexible and reusable. This is just the first step to releasing that anchor.