Hi,
moving config values for modules to a file makes sense and improves the
developing experience only for these two reasons:
1) it would be possible to create module classes for some early loaded eShop
core classes;
2) it would be possible to disable modules if admin does not load because of
some misconfigured module.
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.
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).
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
