Moving aModule from the database to config.inc.php (or a seperate config file) makes sense.
If this change is made, I would ask that you also start the framework explicitly in config.inc.php, rather than via the call to oxUtils::getInstance()->stripGpcMagicQuotes() buried at the end of oxfunctions.php, and change . This would allow 5 additional classes (oxlang, oxsession, oxutilsfile, oxutilsserver & oxdb) to be extended. (See my email "Load Configuration..." from October 9th). CPJ ________________________________ From: Christopher Simon <[email protected]> To: [email protected] Sent: Wed, November 3, 2010 8:53:06 AM Subject: [oxid-dev-general] Suggestion: Put modules from database into an PHP File 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
