User Contributed Preferences
Hooks
Cache user information between prefs_init() calls
Suppressing "whitelist" and "blacklist" menu items



User Contributed Preferences

Perhaps the greatest feature of Horde and all of it's modules is the flexibility to adapt to a myriad of different uses and I would expect that eventually, a more integrated system of managing 'defaults' will become part of the code but at this moment in time, the only way to effect settings system wide is to edit the various prefs.php file inside each module.

In general: Add any local changes to a prefs.local.php or a prefs.d/<name>,php file. Never change prefs.php because this file is overwritten on upgrade and contains vital system information about the preferences that must match the other parts of the system. For instance,

kronolith/config/prefs.php contains:


// Address book(s) to use when expanding addresses ``
// Refer to turba/config/sources.php for possible source values
//
// You can provide default values this way:
//   'value' => json_encode(array('source_one', 'source_two'))
$_prefs['search_sources'] = array(
    'value' => ''
);

To change the default value add the following PHP code to either kronolith/config/prefs.local.php or kronolith/config/prefs.d/name.php name can be any name you like, I prefer the local hostname:


<?PHP
$_prefs['search_sources']['value'] = '["favourites"]';


Hooks

You can provide default values by hooks, which are little PHP functions.

See CustomizingPreferencesH3 for more ideas for preference hooks. Those use the old, no longer supported format from Horde 3, but still may provide some starting points for further customizations. If you port one of those Hooks to a recent Horde version, please add them here.

Since Horde 4 hooks are organized in classes, e.g. config/hooks.php uses class Horde_Hooks, whereas  kronolith/config/hooks.php uses class Kronolith_Hooks. See config/hooks.php for a description of hooks.

For instance to automatically prepare Kronolith's search_sources with all address books the user has access to:

Enable the hook in the local prefs.php kronolith/config/prefs.local.php:
<?PHP
$_prefs['search_sources']['hook'] = true;
</code>

And add to  kronolith/config/hooks.php:


<?PHP
class Kronolith_Hooks
{
    public function prefs_init($pref, $value, $username, $scope_ob)
    {
        if (is_null($username)) {    // not logged in
            return $value;
        }

        switch ($pref) {
        case 'search_sources':    // enable all sources by default
            if ($value == '') {
                $sources = $GLOBALS['registry']->call('contacts/sources');
                $value = json_encode(array_keys($sources));
                $scope_ob->set($pref, $value);
                $scope_ob->setDirty($pref, true);
            }
            return $value;
        }
    }
}

Because the prefs_init hook is called each time an user logins, line 12 shall prevent that the value is set to default each time, probably overwriting the user's choice. The empty string is the default value of the search_sources.

Line 13 collects all address books from Turba, the user has access to. Line 14 prepares the string for the preference. These lines are very preference-specific.

Line 15 and 16 permanently write the settings into the preference storage of the user. The next time the user logins, $value is no longer empty, hence, the if() block is skipped and any newly available address books are not automatically enabled. If you want to keep the preference changing until the user changes the setting manually, remove these two lines.


Cache user information between prefs_init() calls

Because preference values are requested one after another, the function prefs_init() is called for each preference you have set hook = true. If you query large latency databases, it can make sense to query all user data at once and cache the result for the next call of prefs_init. You can use a Horde case for example like so:


function my_userinfo($uid) {
    global $injector;
    $cache = $injector->getInstance('Horde_Cache');
    $key = 'my_userinfo.u.'.$uid;
    if($cache->exists($key)) {    // saved??
        return unserialize($cache->get($key));
    }

    $userinfo = false;

    // prepare the userinfo array here

    if(isset($userinfo)) {
        $cache->set($key, $userinfo, 20 * 60);
        return unserialize($userinfo);
    }
    return false;
}

Save this function in a PHP file and use it in all prefs_init() functions you need the user information, e.g. before the switch($prefs) statement:


    require_once(HORDE_BASE . '/lib/my_lib.php');
    $info = my_userinfo($username);
    if(!isset($info) || $info === false || $info == '') {
        return $value; // error getting user information
    }


Suppressing "whitelist" and "blacklist" menu items

As an administrator you may want to manage all SPAM controls at the server and if so, you'll want to remove these menu items so as not to confuse/frustrate your users.

File to edit: ../ingo/config/prefs.local.php




$_prefs['whitelist']['locked'] = true; 
$_prefs['spam']['locked'] = true; 


File to edit: ../config/registry.local.php



$this->applications['ingo']['provides'] = array_diff(
     $this->applications['ingo']['provides'],
     array(
         'mail/blacklistFrom',
         'mail/showBlacklist',
         'mail/whitelistFrom',
         'mail/showWhitelist'
     )
);