Hi Robert Yeah, like that. But my question was to ask you guys if this idea/concept is worth to implement it into the core. Does it make sense for you and your setups? Do you see any problems arising?
Would it improve the OXID experience? @Daniel Schlichtholz: Sorry for calling you David... 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 anzido GmbH Gesendet: Dienstag, 5. Juli 2011 14:45 An: [email protected] Betreff: Re: [oxid-dev-general] Ats.: Custom components option [T-X651XHZ1GS-75] Hi, you can actually do this quite easily. Just add the following to the end of the config.inc.php: if ( file_exists( dirname(__FILE__) . '/config.inc.local.php' ) ) { include( dirname(__FILE__) . '/config.inc.local.php' ); } This won't throw an error if the file does not exist. If it exists, it will just include it. Putting it at the end of the config.inc.php means that you can override anything you like, e.g. database connection settings and shop urls... Best regards from Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: [email protected] Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -----Ursprüngliche Daten----- Datum: 05.07.2011 13:46:18 Von: development <[email protected]> An: [email protected] <[email protected]> Betreff: Re: [oxid-dev-general] Ats.: Custom components option Vorgang: T-X651XHZ1GS-75 > 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 _______________________________________________ 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
