[dev] default backends

[Jan Schneider]

Zitat von Rui Carneiro <rui.carneiro at portugalmail.net>:

> On Mon, Feb 14, 2011 at 10:50 PM, Ronan SALMON <rsalmon at mbpgroup.com> wrote:
>>
>>  Thanks for this example that clearly shows why the old way was not perfect
>>> and the new way is much better. After these changes, what you to is:
>>> 1. Update the Horde tree.
>>>
>>
>> I agree with Jan here. I find the *.local.php files really handy.
>> Especially when you will upgrade Horde and Horde apps, you'll automatically
>> get the new settings.
>
>
> This is not necessarily good .
>
> The following example might not be the best one, but here it goes:
> - The current default for $_prefs['initial_application'] is 'horde'. When I
> first installed horde I checked prefs and this value was ok for me so I
> didn't overwrite this pref on prefs.local.php.
> - Later on Horde Team decided to change the initial application to 'imp'.
> Now, I end up with an installation where the initial app is 'imp' (that I
> might not even have installed).
>
> To avoid this problem we will need to do the following steps:
> 1- Backup all config/*.php files
> 2- Pull horde code
> 3- Compare every single php with the new ones
> 4- Update our *.local.php with our new defaults.
>
> This is almost the procedure that we do now with the exception that we don't
> need to backup config/*.php files.

This is really a constructed example IMO. If we change some defaults  
in configuration file, we do this for a good reason. You might happen  
to disagree, but chances are good that our changes make sense.

If you think you need to do the steps above with every upgrade now,  
then this is not different from what you have to do today.

It happens all the time that admins do *not* update configuration  
files after updating an application. But I can't remember of any admin  
complaining about a new/changed setting we distributed in a newer  
.dist.php file.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/