Hello David Great ideas! By the way I'm currently thinking about staging solutions in general. How to solve the transition of data configuration etc between development and testing environment or testing and production environment for example.
I think your solution could be a first step to enable OXID to be capable of this from its core. Though I personally don't like to fiddle around with Apache (though I could in most cases). Also to do it by .htaccess I don't like. I would prefer to set "local" settings in a config file called config.local.php or something. The "global" config (as we know it until now) I would put into config.global.php. And a better place for the custom components (and other data in the future) comes to mind: config.custom.php. And I also second your commend about putting these config files into a conf, config or configuration sub directory within the root. So if there is no config.local.php the shop just takes all configuration from config.global.php. If there is, you can overwrite selected parts of all configuration by the local settings. The same goes for the custom settings. We could go even further and allow a config.default.php but I'm currently not sure what to put in there. May be aAllowedUploadTypes or other very rarely overwritten configuration. What do you think? Grüsse aus Basel Marc ORCA Services AG Herrenmattstrasse 26 CH-4132 Muttenz Office Basel: Aeschengraben 10, CH-4051 Basel [email protected] T. +41 61 205 80 80 T. +41 61 205 80 73 (direkt) F. +41 61 205 80 81 www.orca.ch, www.orca-services.ch "We convert your visitors into customers." -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Freitag, 1. Juli 2011 23:16 An: [email protected] Betreff: Re: [oxid-dev-general] Ats.: Custom components option Hi readers and developers, I really appreciate the idea of adding custom components via the configuration. That's much better than all the workarounds which cause a great overhead just to hack a simple setting in oxubase. As a general thought on this I would go a step further: a developer has to deal with local, testing, continous integration, staging and productive environments and - of course - all need different settings. So we had to find a way to handle different environments which need different configuration settings. The way we solved this, is to set up an environment variable in apache's vhost.conf like e.g.: SetEnv APPLICATION_ENV production (In most cases one could also do this using the .htacess file) In config.inc.php we added something like this at the end: // additional configuration values $stage = getenv('APPLICATION_ENV'); if (is_readable(SHOP_PATH .'/config.' . $stage . '.php')) { include SHOP_PATH .'/config.' . $stage . '.php'; } This way you do have all possibilities to extend or replace configuration settings depending on the environment, the current instance is running on. Additionally our customer has a central place to edit configuration settings and we don't need to create an admin view for every single setting (time => costs). It is somehow similar to the way the language array is extended if a file exists in out/theme/language/. Maybe this is a way that could make it into the core? If the file doesn't exist there is no disadvantage (except some microseconds to find out that the file doesn't exist). Additionally I would place all configurations in a sub folder called "config" to clean up the htdocs-root (included files shouldn't be in the document root). In contrast to Marc I do feel, that a configuration file is the correct place to place this. Because that's what we do: extending or changing the standard configuration. What do you think? Best regards from Germany, Daniel Schlichtholz Mayflower Gmbh - [email protected] Pleichertorstraße 2 - Tel.: +49 931 / 35965 - 1125 9707 Würzburg - Fax: +49 931 / 35965 - 28 http://www.mayflower.de On Fri, 1 Jul 2011 13:34:47 +0000, Vilma Liorensaityte <[email protected]> wrote: > Hi, > > At the moment this is a quick fix to make it work. In future we will > search for better solution. > > Besides, if you have any ideas how to improve - please tell us, > working on this task we will consider them. > > Regards, > Vilma > > ________________________________________ > Siuntėjas: [email protected] > [[email protected]] development > [[email protected]] vardu > Išsiųsta: 2011 m. birželio 30 d. 15:28 > Kam: [email protected] > Tema: Re: [oxid-dev-general] Custom components option > > Hi Vilma, > > Great news. > We just discussed this missing functionality at the technical > certification module yesterday in Freiburg! > Will this solution be permanent or are there any plans for an even > more convenient way to do it? > Because I don't think the config.inc.php is really the right place, > though I currently don't have any better place to recommend. > > Regards > Marc > > ORCA Services AG > Herrenmattstrasse 26 > CH-4132 Muttenz > Office Basel: Aeschengraben 10, CH-4051 Basel > > [email protected] > T. +41 61 205 80 80 > T. +41 61 205 80 73 (direkt) > F. +41 61 205 80 81 > > www.orca.ch, www.orca-services.ch > > "We convert your visitors into customers." > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Vilma > Liorensaityte > Gesendet: Donnerstag, 30. Juni 2011 15:15 > An: [email protected] > Betreff: [oxid-dev-general] Custom components option > > Hi, > > According to reported bug > http://bugs.oxid-esales.com/view.php?id=1721, we implemented suggested > improvement for the next release: added $this->aUserComponentNames > array option to config.inc.php. With this option it will be easier to > override custom components array $_aUserComponentNames (class names, > that are defined in this array, will be executed before any other > regular operation) in oxubase. Till now the only way to override this > array in oxubase was extending view classes and sometimes all of them. > > Regards, > Vilma > _______________________________________________ > 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 _______________________________________________ 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
