Hi Chris, I guess is more a normal incompatibility between Modules. Because, if the encrypted modul use a class which is not overloadble with standard oxid behavior, it need a workaround like you use. ;)
Sometimes it helps, if you put an other order in the module-config. Eg: change oxArticle=>myModul&cryptedModul to oxArticle=>cryptedModul&myModul ... and I remember with combinations of extended oxbasket, oxbasketitem and oxarticle you need to try different orders in modul config - but I don't remember which order is right. Tipps for debugging: Open your modul-files and comment all, but not the class defination. If now the third-party-modul works, you can activate one method by an other of your modul/s - till you find the 'bad' method. Maybe then you can find a fix. Otherway, check out, if every extended method from your moduls calls parent::methodName(). And its normally better, if you extend a existing method, to have the same types of parameters and return values like parent. So if the crypted modul needs a string return value and gets an array from your modul, of course it will don't work correct. And maybe the reflection-api helps you to find out a little of the crypted modules >http://es.php.net/manual/de/book.reflection.php Regards, Markus Am Wednesday 09 February 2011 19:02:49 schrieb Chris Jolly: > Hi again, > > I have another couple of questions on this issue. > > I have successfully used the method suggested below by Markus to allow > modules to overload oxutilsfile etc. But I recently had to stop because it > crashed a module from another vendor (not sure why, the module was > encrypted so I can't check). > > (1). Has anyone seen problems with the 2 lines for config.inc.php proposed > by Markus ? > (2). Has anyone seen problems with the 1 line for config.inc.php proposed > by Sarunas ? > > Thanks and regards, > > Chris > > > > > ________________________________ > From: Sarunas Valaskevicius <[email protected]> > To: [email protected] > Sent: Mon, October 11, 2010 9:27:41 AM > Subject: Re: [oxid-dev-general] Load Configuration more early > > Hi, > > > One hint from csimon says there maybe problems with the EE-Version. > > The problem is knowing the shop id, that is currently loaded by user, so as > it may be taken from the session, oxSession instance is currently loaded > first. > > There was the same question posted in this list previously (2010.06.16), > with a pointer to a bug entry: > https://bugs.oxid-esales.com/view.php?id=1097 > > Copying the answer from my earlier reply: > --------- > For now, if this class module is really needed, there is a (not really > nice) workaround to do it. > As aModules config variables is usually taken from the oxconfig table - it > is taken after loading the session. > > For earlier steps this parameter may be initialized in config.inc.php: > > $this->_aConfigParams['aModules'] = array('oxutilsfile' => 'module...'); > > Note: this parameter will get overwritten by loading oxconfig table, so you > may need to duplicate needed module entry here too in some cases. > ---------- > > > Best regards, > Sarunas > > > ----- Original Message ----- From: "dasGollum" <[email protected]> > To: <[email protected]> > Sent: Saturday, October 09, 2010 11:58 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
