Handling the Config(s) of Wikka
As I took a deeper look at the way the config is handeld, I got more and more confused. Perhaps you can help me with my questions.-- NilsLindenberg
1. There is an array called $wakkaDefaultConfig right under the comment default configuration values. But actually these values are no default-config, couse you can not run the program with it (it is missing information about the MySQL-access for example).
My question: do we need to merge this config with the normal one at every call of wikka.php? Or would it be enough to do this in default.php (and putting the array there?)
This would get us rid of the array_merge in wikka.php, which is by the way done three times in three different files (wikka.php; setup/install.php and setup/writeconfig.php.
2. If we can do this, wikka.php just has to prove if there is a wikka.config.php. Otherwise it has to start the installer, to let the user make (a new) one.
3. the variable: $wakkaConfigLocation. This variable is used to print the name wikka.config.php in some files (install and writeconfig), but I can't make sense of it. Why a variable when we don't give the user the choice to change it?
a) if we wont to make the admin change the config_file, we better use a constant, which has only to be changed once in the code, and replace every wikka.config.php (note that it would be necessary to change this again after copying a new version to the directory)
b)if we don't wont that, wikka.config.php should better be hardcoded, which makes the code easier to read and understand.
My idea is to replace the whole current configuration file with an INI file, and a WikiAdmin action to maintain such a file. One important reason is that (as has already become obvious through conversations on this site) WikiAdmins who do not have any knowledge of PHP syntax will easily get into problems editing the config file (and they shouldn't need knowledge of PHP syntax to set up and run a Wikka installation).
An INI file is a simple text file in a well-know format for configuration settings. It can also contain comments and sections to organize the settings into logical groups.
A new installation could come with a "starter" INI file (replacing the configuration array now embedded in wikka.php), and the setup routine could start the Admin action to add any missing values (such as the database access values). No merging, no renaming, easy and user-friendly maintenance (either edit a text file or use the web-based form).
I'm working on a set of classes to allow usage and maintenance of configuration files in the form of INI files - but it's not quite done yet.
Location of the file is indeed an important issue - especially since it contains database access data: preferably the file should be located outside or the web docroot but this means some way of defining, changing and retrieving the path of the INI file must be built into wikka.php. I'm open to suggestions ... :) --JavaWoman
Sorry, i am shurely understanding you wrong, but wasn't there a discussion about an action or something like that, which would allow an admin to change the config through wikka? --NilsLindenberg
Nils, I did mention using and INI file instead of the current (file with an) array before - see for instance WikkaCSS (took a bit of effort to find this back ;-)) - search for "It's obvious that editing a configuration file" to get to it. I've possibly mentioned it in a comment to (instead of in) a page somewhere as well, but currently we cannot search comments :( --JavaWoman
I've now written up my thoughts about a more secure way to handle Wikka's configuration (which should also provide also more flexibility). --JavaWoman
CategoryDevelopmentArchitecture
