[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