Am I missing something, because this seems very simple to me... (1). Why is it necessary to encode the list of plug-in modules and to then store this in the database ? (2). Why is it necessary to start the framework in such a way that 5 classes can't be extended ?
If there are no good reasons for either and assuming the fix is simple, why shouldn't we ask OXID to make this change ? ________________________________ From: Christopher Simon <[email protected]> To: [email protected] Sent: Wed, November 3, 2010 11:22:33 AM Subject: Re: [oxid-dev-general] Suggestion: Put modules from database into an PHP File Hi, I know that it works with a wrapper, still this doesn't solve the "synchronization" issue within development teams. Such kind of "emergency scripts", help for the moment, but they don't fix the source of the problem. btw you can also initiate the shop framework for such a script. Am 03.11.2010 10:40, schrieb Stefan Krenz: > Hi, > > you can edit the module list outside from OXID. > > We need two "wrapper" classes, one for config.inc.php (named as > ConfigWrapper) and one for oxconfk.php (named as ConfKWrapper). > With this classes you can get the required information: > - ConfigWrapper->dbHost > - ConfigWrapper->dbName > - ConfigWrapper->dbUser > - ConfigWrapper->dbPwd > - ConfKWrapper->sConfigKey (needed to en-/decrypt the aModules DB entry) > > Connect to the database, get the content of 'OXVARVALUE' from 'oxconfig' > with the MySQL function 'DECODE' (use 'ConfKWrapper->sConfigKey' for the > second argument). > You will get the serialized array within the module list. Unserialize > and modify it and put the new serialized array into the database. Don't > forget the encryption with ENCODE. > > This will also work with the Zend Guard encoded versions of OXID. > > Regards Stefan Krenz > > > Am 03.11.2010 08:53, schrieb Christopher Simon: >> Hi, >> >> when you work in a team at a shop project, you often have the problem >> that if some team member adds a new module which is used in templates >> and stuff the other team members have to be noticed that they have to >> add new the new modules in their respective test database. (we work with >> virtual machines for each dev). In addition, if a user adds a Module >> which breaks the shop somehow, he sometimes isn't able to remove this >> module because it broke some component which is mandatory for the admin >> area. The module array is saved as a blob, which makes it a little >> tricky to edit modules without the admin area. >> >> Because of this, we do it like this: Delete (or rename) the "aModules" >> entry in the database and put this line in config.inc.php: >> >> >> $this->aModules = tc_modules($this); >> >> "tc_modules" includes this nice little PHP File: >> >> <?php >> return array( >> 'oxbaseshop' => array( >> // standard >> 'oxorder' => 'invoicepdf/myorder', >> ), >> ); >> >> With this small modification, you are able tu put your modules in >> projects under version control (with SVN), and work much more effective >> in teams. If you now include a module which breaks the shop in any way, >> you are able to simply remove it by editing the file. >> >> I would like to suggest this for 4.5. >> >> Only downside: Some "module installers" would not work anymore. I know >> that you are working on "automatic module installer" stuff, but i would >> rather like our solution for the modules, because i think it's much >> easier to maintain a shop without having the modules in database. Maybe, >> our approach and the automatic installer approach are combinable. >> _______________________________________________ >> 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
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
