<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>Personal addressbook not displayed after upgrading</title> 
  <pubDate>Fri, 10 Apr 2026 13:36:21 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/9306</link> 
  <atom:link rel="self" type="application/rss+xml" title="Personal addressbook not displayed after upgrading" href="https://bugs.horde.org/ticket/9306/rss" /> 
  <description>Personal addressbook not displayed after upgrading</description> 
 
   
   
  <item> 
   <title>We are a mid-sized ISP in Central Switzerland.

After addi</title> 
   <description>We are a mid-sized ISP in Central Switzerland.

After adding an UTF-8 locale,  e.g. en_US.UTF-8 to the system locales so customers would be able to display e-mail messages in UTF-8 encoding, and private addressbooks of customers having entries containing special characters like Umalut, etc, no data will be displayed. We have stored data on a mysql 5 server using the &quot;iso-8859-1&quot; character set and indicated that fact within config/conf.php by telling:
$conf[&#039;sql&#039;][&#039;charset&#039;] = &#039;iso-8859-1&#039;;

After turning on display_errors within php.ini, the following error messages apper:
&quot;Warning: array_values() [function.array-values]: The argument should be an array in /var/www/horde/turba/lib/Driver/prefs.php on line 32

Warning: Invalid argument supplied for foreach() in /var/www/horde/turba/lib/Driver.php on line 541&quot;

First, we tried to change the setting within turba/config/sources.php:
&#039;charset&#039; =&gt; NLS::getCharset()
to
&#039;charset&#039; =&gt; &#039;ISO-8859-1&#039;
But that has changed nothing. After investigating a bit, we&#039;ve seen within the file &quot;turba/lib/Driver/prefs.php, &quot;de-serialization will be done after converting the character set from ISO-8859-1 to UTF-8. That leads to a failure to unserialize the whole addressbook because the byte-length indicated before does not any more correspond to the effective byte-length of the respective string if the user had entered special characters (ASCII Code &gt; 127).

All other functions are working as expected even using an UTF-8 enabled system locale, e.g. all other settings stored within the prefs backend like Identity, E-Mail settings, etc. So I assume there must be something wrong/different with turba prefs storage functions compared to the other prefs functions.

For example, within lib/horde/Identity.php starting at line 87, it let me assume that at least some tries are being done with and without charset conversion so there is a chance to handle both situations (conversion needed and not needed before unserialization):
        if (!($this-&gt;_identities = @unserialize($this-&gt;_prefs-&gt;getValue(&#039;identities&#039;, false)))) {
            /* Convert identities from the old format. */
            $this-&gt;_identities = @unserialize($this-&gt;_prefs-&gt;getValue(&#039;identities&#039;));
        } elseif (is_array($this-&gt;_identities)) {
            $this-&gt;_identities = $this-&gt;_prefs-&gt;convertFromDriver($this-&gt;_identities, NLS::getCharset());
        }

As a workaround, we have to either leave all including the system locale to not using UTF-8 and further live with e-mail messages using non-iso character sets not being displayed directly (until after clicking the link opening a new window in the respective encoding). 

Another possibility could be converting all data within the database to UTF-8 (and swithing to utf-8 within configuration of course), but that leads to even more problems with serialized data within e.g. the whole preference settings (no data is displayed e.g. for Identity settings, etc.) because data would then be stored as UTF-8 strings, but the byte length indicated will be wrong).

Attached you will find horde and turba configuration files.

Thank you in advance for some help or even better a fixed version so we are able to use ISO-8859-1 within the databaes, but display content as UTF-8 as it seems to be possible.

Regards,
Michael Rhyner
Medianet AG</description> 
   <pubDate>Wed, 13 Oct 2010 16:56:15 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/9306#t60402</link> 
  </item> 
   
  <item> 
   <title>horde test pages</title> 
   <description>horde test pages</description> 
   <pubDate>Wed, 13 Oct 2010 17:04:26 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/9306#t60403</link> 
  </item> 
   
  <item> 
   <title>php status page</title> 
   <description>php status page</description> 
   <pubDate>Wed, 13 Oct 2010 17:05:22 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/9306#t60404</link> 
  </item> 
   
  <item> 
   <title>Does it work if you change the &#039;charset&#039; parameter in config</title> 
   <description>Does it work if you change the &#039;charset&#039; parameter in config/sources.php to:
&#039;charset&#039; =&gt; NLS::getCharset(true)</description> 
   <pubDate>Thu, 21 Oct 2010 10:55:08 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/9306#t60533</link> 
  </item> 
   
  <item> 
   <title>&gt; Does it work if you change the &#039;charset&#039; parameter in conf</title> 
   <description>&gt; Does it work if you change the &#039;charset&#039; parameter in config/sources.php to:
&gt; &#039;charset&#039; =&gt; NLS::getCharset(true)

I&#039;ve tried all sort of:
NLS::getCharset(true)
NLS::getCharset(&#039;ISO-8859-1&#039;)
NLS::getCharset(&#039;UTF-8&#039;)

but the address book was not displayed.

Best Regards,
Mike Rhyner</description> 
   <pubDate>Mon, 08 Nov 2010 08:23:50 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/9306#t60764</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
