[dev] [commits] Horde branch master updated. 89ba60ebd8227e84abe696131778097c4770d99d

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

>> Well, that's where the idea for two files comes from. One lists  
>> what we think good defaults are, describes all of the settings,  
>> lists options, etc. The second, which is entirely optional, allows  
>> users to override the defaults without changing a file that is part  
>> of the distribution.
>>
>> Think of it this way: with this system users automatically get new  
>> config settings while maintaining their customizations (except if  
>> the setting they're overriding changes, of course - no way around  
>> that). And if we pick good defaults, then there are fewer things  
>> needed to do out-of-the-box to get Horde up and running.
>
> It makes more sense to me then to have .xml configuration  
> descriptions like we do with conf.php now, and ship default,  
> pre-generated .php versions for that.
> The .xml generated configuration is pretty cool IMO, admins don't  
> have to edit PHP code files, if they don't want to, and still have  
> the full flexibility. And we only have a single configuration file.

But Horde can still be broken on upgrade until running the config  
interface, and if we were to change something really key in horde's  
config.php, theoretically you'd *have* to fix the file manually.

Having two files means that user changes are preserved, defaults can  
be pre-generated easily, and we can *still* provide a config UI,  
either based on xml, or parsed out of the defaults file.

Built-in hooks for a secondary local config file also helps people out  
who are changing specific things on specific servers, or doing  
vhost-like config changes.

-chuck