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 -- Stefan Krenz Mayflower GmbH Pleichertorstraße 2 Tel.: +49 931 359 65 1163 D-97070 Würzburg Fax : +49 931 359 65 28 [email protected] http://www.mayflower.de Mayflower GmbH, Standort Würzburg Firmensitz: Mannhardtstraße 6, 80538 München Registergericht: Amtsgericht München, HRB 142039 Geschäftsführer: Gregor Streng, Björn Schotte, Albrecht Günther, Johann-Peter Hartmann _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
