[horde] 5.2 upgrade : fatal error while editing prefs for imp

Michael M Slusarz slusarz at horde.org
Fri Sep 5 21:31:46 UTC 2014

Quoting Nels Lindquist <nlindq at maei.ca>:

> On 9/3/2014 1:12 PM, Michael M Slusarz wrote:
>> Quoting Nels Lindquist <nlindq at maei.ca>:
>>> On 9/1/2014 11:43 AM, Michael M Slusarz wrote:
>>>> You did NOT read the instructions at the top of the file.  Do
>>>> NOT copy prefs.php to prefs.local.php.
>>> Wait, what?
>>> The file explicitly states not to modify prefs.php directly, but
>>> it doesn't mention anything about not copying prefs.php to
>>> prefs.local.php in order to have a template for overrides.
>> * See horde/config/prefs.php for documentation on the structure of
>> this file. * * IMPORTANT: DO NOT EDIT THIS FILE! * Local overrides
>> MUST be placed in prefs.local.php or prefs.d/.
>> The definition of local overrides is in horde/config/prefs.php,
>> which is explicitly referenced.  Seems very clear from the name and
>> the definition that prefs.local.php contains ONLY local overrides,
>> not a copy of prefs.php.
> I don't have a definition of local overrides in my
> horde/config/prefs.php file.  I searched for "ocal overrides" and
> there's exactly one instance of it, which is identical to what you've
> quoted above.

Looks like this:


Not to mention that configuration is also mentioned in docs/INSTALL:


> There *is* an example prefs file which I clearly should have paid more
> attention to, but in my defense I'd argue that nine comment lines out
> of 260 or so at the top of the file makes it pretty easy to downplay
> its importance.

I accept if we provide documentation and it is  
confusing/incomplete/inconsistent.  That should be fixed.

But the argument of "prefs.php is huge and the comments on the top are  
small so they must not be important"?  That is a non-starter to me.   
By that logic, an admin is never at fault because they shouldn't be  
expected to read the documentation.

> I would be happy to provide some suggestions.  Let's do it in one go,
> though, so there are a couple of other things I now realize I could
> use clarification about first.

Looks like Jan added some additional text to the prefs.php files  
yesterday in git.

> - From the top of horde/config/prefs.php:
> "If you change these preferences in a production system, you will need
> to delete these preference entries in your backend; entries in the
> backend have priority over the default entry."
> Is it safe to assume this refers solely to users' stored preferences
> which likely include previous defaults, or is there anything more to
> worry about?

Preferences are only stored in backed storage if they are different  
from the default.

> Also, just to confirm, my understanding of the order of preference
> loading is config/prefs.php, config/prefs.local.php,
> config/prefs-[virtualhost]*.php, config/prefs.d/*.php and then users'
> stored preferences, with the last-loaded preference being the
> effective one.  Is that correct, and true across all Horde
> applications as well as core?

Not quite.  You have the order wrong (you are correct that all Horde  
config files, not just prefs, are loaded with the same order  

Correct order is:
   - prefs.php
   - prefs.d/*.php
   - prefs.local.php
   - prefs-[vhost].php

After loading all of these, this is the canonical preferences  
definition for that particular system.  It includes not just  
preference values, but also UI-related data.

For prefs.php, there is the additional step where ONLY preference  
values can additionally be modified by the prefs backend storage  
(UI-related prefs data is not affected).


Michael Slusarz [slusarz at horde.org]

More information about the horde mailing list