[dev] Changing configuration file format
Michael M Slusarz
slusarz at horde.org
Fri Jun 7 20:14:38 UTC 2013
Quoting Jan Schneider <jan at horde.org>:
> Considering the increasing post to the mailing lists of people
> having problems creating their *.local.php files, we should consider
> going back to a line-oriented configuration file format, like we use
> in the generated conf.php files.
> I prefer the current format too, but especially for less experienced
> administrators it's much easier to copy single lines from a
> backends.php file to a backends.local.php file and just change their
> values. Building such a line from the current nested hash structures
> is impossible without at least some PHP knowledge, and still tedious
> even for experienced administrators. This often ends up in users
> copying the complete configuration hash into the *.local.php files
> which is exactly what we *don't* want.
I disagree. It is going to make the examples unreadable.
When we first made the change to the *.local.php files, I did this for
an example file and it just killed my eyes (it's bad enough with the
conf.php files - it's impossible to find anything in there). Just
imagine IMP's prefs.php in this kind of format. It would be a 100KB
file - this is just making it MORE difficult to figure out what to
copy/paste and making it more likely that someone is just going to
copy the whole file over and change that, which
For the record - the probability that admin's were going to copy/paste
the entire file was one of my arguments against moving to *.local.php
files in the first place. While I agreed that it makes sense from an
upgrading persepective, the issue IMHO is that no other software does
things this way so it is not intuitive to an admin. That is where
most of the confusion is coming from, not the PHP formatting in the
file.
I think the more proper solution(s) in H6 would be one of the following:
1. Force an admin to run an upgrade script, where these kind of things
could be checked for. In the PHP world, you can take a look at
http://galleryproject.org/ as an example of how this works. (This is
much preferable to trying to do upgrade tasks via the Horde_LoginTasks
mechanism, which has always been sort of a hack).
2. Unify all configuration files into a single file with a common
configuration syntax, to reduce admin confusion.
3. Make everything a "preference", since we already have a system in
place there to automatically upgrade default values.
michael
___________________________________
Michael Slusarz [slusarz at horde.org]
More information about the dev
mailing list