Open kojoty opened 8 years ago
I think that cleaning up the mess around the configuration is a good idea and we should do that!
My comments:
From my point of view it can be done in a steps:
There are a lot of work, but this seems to be quite easy to do...
One point I whish to stress greately: Current implementation with $config in settingsDefault.inc.php seems straightforward and reminds me of MediaWiki style configuration. And it seems very ok to me, simple, easy to undestand (IMHO).
However there is a huge drawback in the way it is currently written. In settingsDefault.inc.php $config is defined as an entire array. In settings.inc.php one would redefine single elements of $config and they way it has to be written is totally different. And this creates confusion. Maybe a lot of confusion.
Since PHP syntax allows it (and this is a good thing), in both files the way it is written should be identical (and portable = copyable) from one file to the other.
From maitenance and administration perspective, having the defaults defined in a file in another directory I believe is more of a headache then help. I am not sure if the class based definitions would be as easy + simple to handle as $config array.
One point is about defining data structures for the OC application and another point is defining configurable settings with default values.
Please take a look at $config['limits'] at the bottom of settingsDefault.inc.php. This is the way I would proceed. Same code can be directly taken with copy/paste to settings.inc.php and values changed to whatever that node's sysadmin desires. Simple as that.
And of course, with all the necessary changes throughout the code to use the new array elements.
Using a lot of global variables definied in settings.inc.php is not very good solution since we use some OOP in opencaching. (variables are not visible inside of classes).
I'm also against adding more and more things configurable per node. This make code more misty. This is bad way to change scripts logic depend on site.
Forgive me, but what would be the good way of configuring things on a per node basis? for example: node 1 wants attribute theme X, node 2 wants attribute theme Y. Node 1 wants to limit images to 640x480. Node 2 wants 800x600 (maybe they have more storage) Node 1 wants special banner for april fools. Node 2 does not. etc. etc. etc. There are lots of others. Some of them are currently not possible.
I don't believe a well chosen names for a configuration item increases confusion (mistyness) in the code.
I am not sure what problems does $config array creates in the OOP sections of the code, but I do support moving all configuration variables currently indeed declared as individual global variables in settings.inc.php to $config or a similar structure, while taking into consideration the aspects outlined above.
We have common system, so why should we split logic for more combinations? Better is find solution common for all nodes. Configurable things should be used only for simple personalizations like site name, datetime format etc. Spliting engine logic for each node sepratelly is time consuming and leading to incompability. We can add thousands if's fore every thing, but is it really what we want?
I am simply asking how can personalizations such as those described above be acomplished?
Another example: how can one set the panorama banner on the top of the page on a per node basis? OCRO may whish to show images from Romania. OCNL may whish to show images from the Netherlands...
One node may whish to use Google Map as default map layer. Another node may whish to use OSM as default map layer.
examples can go on. It is very useful to have things configurable. it may not necessarily mean lot's of if's, but rather the use of a configuration variable instead of a predefined value.
About the maps. This is remembered by cookie. So user will choose what map he gets on the screen. Except the small map on mainpage.
But there is a default map layer before a user may change it.
Also, the small map on mainpage is Google Maps only (not configurable). The small map on cache page is Google Terrain only (not configurable).
I think this is the look of all oc sites. oc.de and oc.us uses the same maptype on mentioned pages. That makes the OC sites as one.
@harrieklomp would you like to have the top panorama show images familiar to dutch people?
@harrieklomp Also, consider not only the exact visual look, but the principle: on that page, in that location, the map is shown. "the map" is a specific entity. The map is still the map. Having a different default layer per site is no different then the fact that once the user changes the layer, this is remembered in a cookie, and next the map is shown (map as entity) but with the remembered layer ?
Another example: OCPL has MAPv3 with Google Map, Google Satelitte, OSMapa, UMP as available layers. OCRO and OCNL have MAPv3 with Google Map, Google Satelitte, OSM as available layers.
For example the UMP layer is polish only, totally useless in countries other then Poland. Having it active on OCPL is a good thing. Having it active on OCNL/OCRO would be useless and counter-productive towards your own users.
There are/can be several alternate layers available as defined in configuration, see settings-example.inc.php, look for $mapsConfig. Including instructions on how to define more.
IMO this is a good thing.
@andrixnet . When you look at those pictures in /images/head you can see different countries. For example i can see pictures who can be made in Belgium, the Netherlands or even in Luxembourg. Now this is a international site, i am happy with it. If you like you can add one or two pictures from Romania.
The thing is there are quite a number of personalizations that absolutely require that a node operator is also a developer and that changes be made in the project repository. IMO this is conceptually wrong.
Colleagues, Generally, I think we all are right - I mean that the dispute is virtual:
I think that the $config[] style is a great form of preparing configuration files, but the ocConfig class should be the only one which reads files which contains this $config[] array.
Now I'm sure that we also need modules in configuration to prepare for for more config variables. Let me show you my vision of it - I'll prepare doc with my vision of solving it ok?
Sure. i will eagerly wait to see it. I opened this issue for just that purpose, to discuss a better way of improving config, taken from many points of view, and acomplish this as a team. I definitely did not want to start making changes that would perhaps undermine other people's work.
Changes to the configuration subsystem will proceed using the following (rough) roadmap:
@andrixnet, First, I'd like to ask you to suspend works on it till the end of removing mysql_* (#276). I'm going to start work at this this week and I suspect it takes 2 maybe 3 weeks (it depend how much time I will have for oc).
Second, My part of vision for this change:
OcConfig::GetOcNodeId()
, which read and return the value $oc_nodeid
from current settings file$oc_nodeid
should be updated to OcConfig::GetOcNodeId()
- (there is a work across many files but I think It's possible) - it needs to be done for all vars from current config...OcConfig
class$config['key'] = 'value'
; or whatever we choose + comment, examples etc.OcConfig
class. OcConfig
uses at this point old-style configs (by default) but there is a "switch" which makes OcConfig
works with "new-style" configs only. This "switch" is located in a new-way config files.OcConfig
classI think I can prepare all the necessary changes in the code for this and drive the whole process, but I would like to finish current works first.
Very well, I can postpone until then. However I can edit settingsDefault.php with proposed new configuration variables, all commented.
As discussion on your points:
$config['server']['db']['host'] = 'localhost';
$config['server']['db']['port'] = '3306';
$config['server']['db']['database'] = 'ocpl';
$config['server']['db']['username'] = 'db_username';
$config['server']['db']['password'] = 'my_password';
$config['server']['path']['root'] = '/path/to/ocpl';
$config['server']['path']['dynamic'] = '/path/to/oc-dynamic';
// of course there can be config variables on 1 or 2 levels as well.
They are clearly structured from both human and machine point of view. Admins can easily locate and manage config sections. Grouping also allows handling that group individually in the code and also modularization (see 1.2. above)
I will try to prepare as much as possible of config variables (as comments only) in settingsDefault as a place to start.
Follow my progress here: https://github.com/andrixnet/opencaching-pl/tree/settings
OK, DB refactoring is generally over - it's time to come back to configuration...
I created doc to preset my idea of oc settings refactoring - fell free to comment: [https://docs.google.com/document/d/1LdJi2O-RVCT6lE0VEGrDqO1zPJnBUfTzggqjZSpLyXA/edit#]
I disagree with point 4) in the implementation plan. It needlessly complicates administration task, in a pure developer oriented way.
Please take a look at: https://github.com/andrixnet/opencaching-pl/blob/settings/lib/settingsDefault.inc.php
Structuring project level defaults here on several levels ensures that the configurations can be dynamically read and interpreted, even without dedicated configuration handling code for each variable.
settings.inc.php (or similar) single configuration file for the website is a good idea from administration point of view. It contains the subset of variables from settingsDefault.inc.php, those which are mandatory to be set locally and any optional variable that needs to be redefined.
Although some sysadmins may have PHP skills, editing configuration as ... php classes is a big no-no.
There are also items in current configuration which do not belong there. See https://github.com/opencaching/opencaching-pl/issues/299 These should gain priority before changing config.
Regarding config handling (with advice from a friend with much more PHP experience then mine): $config as a global resource is much more efficient. It is a better idea then individual variable names for each setting, because only one variable (namely $config) needs to be referenced anywhere in the code and have all the settings at your fingertips.
Making it and it's components into a class / classes adds unjustified memory and CPU penalties. But is it really necessary to rewrite all the settings two more times? (once as class properties and once more as class getter methods)
@andrixnet: