Bootstrap process refactored in 4.7 5.0

The so called “bootstrap process” (further called BP) is the initial script that includes, defines and initializes all methods required for the OXID eShop framework to work correctly. What we wanted to achieve is to make this BP lean and performant again as the former one was grown historically. We could increase the starting time, remove incomopatibilities between different points of entry and decrease limitations such as the possibility to override specific methods according to the usual module system. Additionally, during the refactoring, we found some circular references that of course had been removed.

In particular we changed the following:

BP defined exactly

OXID eShop execution has been split into two clear parts: BP and the rest of the framework. BP is now entirely isolated to a new bootstrap.php file. This makes it very easy to include this file into your script everywhere you need a framework initialization.

Here is an example for the new index.php:

require_once dirname(__FILE__) . "/bootstrap.php";

These two lines are enough to fire up the framework and start (and complete) the shop execution. You can as well include bootstrap.php to any entry point for any of your projects.

BP is lightweight and fast

The main task of bootstrap.php is to read main, to initialize the DB connection (but not to make an actual connection yet) and to define the __autoload(). The rest of the initialization process needed in most cases (actually DB connect, module system init, config variable lodaing from DB, session init) is done on demand, on the first related function call. This way the present BP is very fast. We checked it on our machines with a script containing only the bootstrap.php file with the result that BP took only 2% (15ms) of full start page execution time.

Singletons are replaced by registry

Previously, in order to get the instance of certain classes, we were using Singleton design patterns, for example:


There are critics aroeund about using Singleton patterns, as some guys consider it as an “anti-pattern”. We were considering what would be the best option to replace singeltons for some time now and decided to use registry design pattern. The example below shows how to get the single instance of utility classes using the registry:


In this example oxRegistry::get() getter takes object name as a string parameter and returns an instance of oxUtils class. The oxUtils object is instantiated on the first attempt to get it. The object is stored in Registry and later the same object is returned on every get(“oxUtils”) attempt.

The same applies to oxConfig and oxSession classes, you can get the instance using oxregistry::get() method, or even better, you can use already prepared shortcut methods:

$blShowArticles = oxRegistry::getConfig()->getConfigParam(‘blShowSomething’);
$oSession = oxRegistry::getSession();

For more details, please see the oxRegistry class implementation.

oxConfig and oxSession are now overrideable by modules

Yes, finally they are! This kind of module class is a valid module for oxSession class:

class mySession extends mySession_parent
     public function start()
         echo "SESSION STARTED";
         return parent::start();

The same with oxConfig. Just a stupid example, but it works:

class myConfig extends myConfig_parent
     public function getConfigParam( $sParamName )
         echo "$sParamName.";
         return parent::getConfigParam( $sParamName );

Have fun with this new concept 🙂

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *