I agree with Markus that the call to _loadVarsFromDb() in oxconfig->init() occurs too late in the initialization sequence.
The call to oxUtils::getInstance()->stripGpcMagicQuotes() at the end of oxfunctions triggers a cascade of class includes & object instance creations. In this sequence, by the time it reaches _loadVarsFromDb() in oxconfig->init(), and loads aModules, several classes, including oxlang, oxsession, oxutilsfile, oxutilsserver & oxdb have already been created and loaded into _aClassNameCache in oxutilsobject, which prevents modules extending these classes. It seems odd to initialize the framework through a call to stripGpcMagicQuotes(), buried at the end of oxfunctions.php. The way that oxconfig->init() eventually gets called, results in what seems to be a random set of classes being excluded from module extension. If there is some reason why these particular classes are chosen for exclusion, it's not obvious. The solution suggested by Markus to call _loadVarsFromDb to load aModules in config.inc.php works, but clearly the proper way to implement this would be to move the function call to the beginning of oxconfig->init(), just after the include for config.inc.php. Calling _loadVarsFromDb to load aModules at this point means that only oxutils and oxdb are already in _aClassNameCache. Any further classes that pass through oxutilsobject->getClassName() after that point can be extended. Conclusions: (1). Oxid should consider changing oxconfig->init(), calling loadVarsFromDb to load aModules at the beginning, not half way down (2). Oxid should consider explicitly initializing the framework by creating an instance of oxconfig & calling init() before oxUtils::getInstance()->stripGpcMagicQuotes() gets called. Regards Chris www.ontraq.eu ________________________________ From: dasGollum <[email protected]> To: [email protected] Sent: Sat, October 9, 2010 10:58:55 AM Subject: [oxid-dev-general] Load Configuration more early Hi all, based on this thread >http://www.oxid-esales.com/forum/showthread.php?t=6604 there are in several updates problems with modules. Here was not possible overwriting eg. oxlang (4.4.1=>4.4.2). So all modules which uses oxlang are not working anymore. The solution is load the config before any other action. Insert at end of config.inc.php: include getShopBasePath().'core/oxconfk.php'; $this->_loadVarsFromDb( $this->getShopId(), array('aModules') ); Of course, its better in the oxconfig directly after including oxconfk.php ... but oxconfig is a core file. So there is a central point which loads the aModules very early from DB. One hint from csimon says there maybe problems with the EE-Version. So my questions: - what problems? - is it possible to solve these problems? Because I like the chaining of oxid, and wanna will use it so far as possible. So I think, this should be in the core, if possible. And its a really not nice, if you make a update and there moduls which can't work anymore. Regards, Markus _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
