There have been some migrations of Horde 3 to Horde 4 recently – not all went smooth from the start.
Some top issues of messing things up and how to avoid it:
- initial application dimpIn Horde 3 dimp was a separate application which provided an ajax interface to imp. It has since been merged into the imp application. If your Horde installation had dimp before migration to Horde 4, this might create runtime issues for your users when
- when you locked the initial application to dimp
- when your users decided that their initial application should be dimp
To get around this you should
- make sure you didn’t blindly copy your locked settings from horde 3 to horde 4
- run a mysql update statement on the horde_prefs table to update column pref_value to “imp” if it was “dimp” before (Consider hiring a professional admin for the migration if you don’t know how that looks like)
- Making changes in backends.php or prefs.php
In Horde 3 admins used to edit prefs.php or backends.php/servers.php to change values. Horde 4 ships backends.php and prefs.php as default values. Admins are supposed to copy these to backends.local.php and prefs.local.php and make their changes there. Changes to the original files will be overridden with the next rpm or pear update of the horde apps. - Not unchecking utc time in kronolith
The Horde 3 Calendaring app defaulted to store calendar events in local user time. The Horde 4 default is UTC timestamps. If you migrate from horde 3 you either have to uncheck that setting or run a migration script on the data.
Warning: You might end up with an unrecoverable state if you add new data in UTC mode to a calendar backend which has not been converted to UTC timestamps - Not converting turba and kronolith databases to utf8
In Horde 3 installations, the calendar app kronolith and the addressbook turba often had their database tables encoded in latin1. The system wide default in Horde 4 is utf8. Not adapting this setting to the tables or the tables to this setting results in corrupted display of international characters and symbols.
Warning: You might end up with an unrecoverable state if you add new data to addressbooks or calendars where backend encoding does not match the set horde encoding - Relying on menu.php’s javascript onclick handler or target attribute
In the ajax views of kronolith and imp there is currently no support for the target and onclick handler attributes. I do not know of any plans to re-add this support. If you want to link external sites into the iframe, consider creating a custom portal block. There was a recent blog post on creating this kind of blocks on The Upstairs Room - Using the ldap prefs backend
The ldap backend for preferences is currently not yet ported to horde 4. If you want to migrate, you first have to extract your prefs from ldap and then convert them to sql. If you need ldap prefs, consider hiring a consultant or sponsoring the development of this feature.