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
