Hi,
Am 08.11.2010 14:10, schrieb Sarunas Valaskevicius:
Still, the mentioned downside about the module installer is a heavy one
- moving the module class configs could be thought as going to the
opposite direction.
in my last mail i mentioned the way of "generating" the file by an
autoinstaller with var_export (which produces valid php code) and
file_put_contents. Also, the file could be generated with an shop Id, or
we could use the same file for all shops with different array keys. This
is one way it could be done, there are more solutions (maybe cleaner
ones) open.
Btw: in ee you have 1 aModules array in config for every mallshop, but
every aModules array has a key which determines which shop the modules
are for. isn't this redudant or am i wrong? If the shop id is already
included in the aModules array, there is no need for generating files
with suffix at all.
Also, just moving config values loading earlier or getting it from file,
would disable the possibility to enable different modules for different
subshops, which use the same domain (for EE, see topic "Load
Configuration more early" in this list).
Like i suggested: It could be a solution to work with filename prefixes
for Mallshops. This could be realized with slight modifications on the
shop core, it wouldn't be hard to implement this behavior.
We are working on a solution that would address all four mentioned
problems.
Best regards,
Sarunas
----- Original Message ----- From: "Christopher Simon"
<[email protected]>
To: <[email protected]>
Sent: Wednesday, November 03, 2010 9:53 AM
Subject: [oxid-dev-general] Suggestion: Put modules from database into
anPHP 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
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
