Yes, it did.

Seems to be solved by commit f5c41a4c0aeb6fdd631c63687dfba15da4c5125a

First it makes no sense to create two (different) prefs objects in one session
  - one stored in the registry
  - one created temporary in Horde_Core_Topbar::getTree()

Secondly:
If the creation of the temporay prefs object fails a notification is set up:
The preferences backend is currently unavailable and your preferences 
have not been loaded. You may continue to use the system with default 
preferences.

This isn't  true because the "registry prefs object" works fine and i 
continue with the settings of this prefs object

Thirdly:
If Horde_Core_Factory_Prefs::_notifyError() is called in case of an 
error, errors of the
other prefs object are never logged or displayed because:
$GLOBALS['session']->set('horde', 'no_prefs', true);
To be consistent, each prefs object should have it's own 'no_prefs' 
marker, not the session.

Conclusion:
One session - one preferences object

That still doesn't answer my question. The question was why it would a 
problem to have two prefs instance, not to have a pref instance for 
guest users.

I am refactoring the Prefs LDAP-Driver using the Horde Ldap class

The Driver can not bind to the LDAP directory as user
without having a username set.

Of corse this could be checked in Horde_Prefs_Storage_Ldap class.

But Preferences belongs to (logged in) users and therefore a username 
should be set.

I would use something like this to check the Prefs type:
!($GLOBALS['prefs'] instanceof Horde_Prefs_Session))
instead of creating a new object (principle question)

$GLOBALS['prefs'] should be set at logged in users

Heinz

And what's actually the problem with creating two prefs instances?

Hi

In  function getTree() of the class Horde_Core_Topbar the menuentry 
for preferences is conditionaly created by
checking $registry->showService('prefs') and the type of the backend 
by calling:
($GLOBALS['injector']->getInstance('Horde_Core_Factory_Prefs')->create() 
instanceof Horde_Prefs_Session))

Here Horde_Core_Factory_Prefs->create() is called without parameters!
Because of the missing $opts, the Factory creates a new Prefs object 
and don't return
a previously created e.g. by the Auth system.

Some underlaying Preference Storage Drivers may require at least 
username and password,
which are set empty at the beginning of 
Horde_Core_Factor_Prefs->create() in the case of not
providing username and password by $opts.

So, with an empty username the Preference Storage Driver may fail
eg a database backend driver trying to bind as user (eg LDAP directory, ...)

Should a blank username be handled by the Preference Storage Driver ?!? No.

Instead of calling
$GLOBALS['injector']->getInstance('Horde_Core_Factory_Prefs')->create()
i think
$registry->loadPrefs()
would have the same effect (but sets a correct username/password)


Sincerely,
Heinz Schweiger