I made the change in HEAD and resolving.

That did it...



Thanks, Mike!

In HEAD, try changing line 256 in framework/Horde/Registry.php from:

register_shutdown_function(array($this, '_shutdowncache'));



to:

register_shutdown_function(array(&$this, '_shutdowncache'));



and see if that helps any.

Ok. For those keeping score this is what I've been able to find out so far.



* Problem occurs (for me - and on multiple installations / machines) 
with php 4.4.x including recent development checkout from cvs.php.net. 
  Problem does not occur with 5.1.2.  Again, problem only occurs when 
calling a horde application's api method from a configuration screen.



* The order that the function calls occur is different under php 4 and php 5.



In php 4.3.x -> 4.4.x I get:

===============

   Registry::clearCache

   Registry::_shutdowncache  (at which point $this->_nocache is false 
for some reason)

   Registry::Registry (constructor)





In php 5.1.2 I get:

===============



   Registry::clearCache

   Registry::Registry (constructor)

   Registry::_shutdowncache (at which point $this->_nocache is once 
again false)





I think what's happening is that even though it appears that php4 is 
actually giving the expected call order (at least what I would expect 
it to be), Registy::_shutdowncache is being triggered after the 
registry object's class variables go out of scope somehow, but before 
the session data is saved. So, when _shutdowncache is called, 
$this->_nocache is always false and we are not left with an unset 
$_SESSION['_registrycache'] by the time we get the to Registry 
constructor.  At this point I always have 
$_SESSION['_registrycache']['_confcache'] still set.



In php5, $this->_nocache is still false when checked in 
_shutdowncache, but at this point, since the Registry constructor is 
called before Registry::_shutdowncache, we are always left with an 
unset $_SESSION[_registrycache'] and are forced to reload registry.php



Quick hacks to fix this would be to either call session_write_close() 
after we call Registry::clearCache - but I guessing this is a Bad 
Thing.  The other option, which I'm currently using is to unset 
$_SESSION['_registrycache']['_confCache'] if it is set in the registry 
constructor.



I've got code to commit to provide a drop down menu with address book 
sources for Turba's 'client address book'  setting (see Bug: 3271)   
I'm hesitant to commit this as I'm sure I'm not the only one who would 
have this problem...

Works fine here with 4.4.3-dev and apache2.

Yep. I'm running older versions of both on dev machines.  When I get 
the time I'll set up a PHP 5 enviroment and see if that fixes.  In the 
meantime, I'll try to continue to work this, can anyone else that's 
running PHP4 (I'm on 4.4.1 & 1.3.3 of Apache) could verify if this 
does or does not work for them?

I'm running out of ideas.  What version of PHP are you running?  I'm 
at 5.12 w/Apache 2 so if you are running older versions of either 
maybe they have fixed some bugs since then.

Looks like you're back to debugging then. Though I don't understand 
why this might happen. We redirect to a new page *immediately* after 
clearing the cache now, so it should be rebuilt on the next possible 
situation.

Now it's failing earlier.  Before, when I generated a new conf.php, 
the page would refresh and show the new configuration.  It would fail 
when I attempted to go to any other page after that.  Now, it's 
failing when I attempt to generate the new conf.php, before the page 
reloads.  It appears the new conf.php is written before it fails though.



Please let me know what else I can check or attempt to help...



Thanks.

Should be fixed now.

OK. I'm in unknown territory here with the cache code so please bare 
with me... Looking at the keys that are being updated in 
__registrycache this is what is happening -



When loading the setup page that contains the api call - the 
['applications'] and the ['_confcache'] entries are being updated.  I 
don't think the problem is with calling the api function though.  If I 
load the setup page, I see the expected values.  If I exit the page 
without saving anything everything is fine.



When you generate conf.php, the only key that is being updated is 
_confcache...but that also seems to be the behavior when using a setup 
page that does not include an api call as well.



I have no idea if this is expected behavior or not...

I would suggest setting some checkpoints in _shutdownCache() to figure 
out if/why that code is updating the cache.  Since I can't reproduce 
the behavior, I can't do any more debugging at this time.

BTW, tested on both HEAD and FRAMEWORK_3 ...

OK, I tried it on a second installation, different machine - still not 
working.  I updated yet again, updated symlinks for framework - 
verified the framework files that are being used are the most up to 
date versions...verified the admin/setup files are most recent...what 
else?

I updated again with: cvs -q update -PdCA to be sure then updated the 
framework packages again for good measure, reapplied the patch and I'm 
still getting the error....is there something else I am missing?



When I get some time, maybe later today, I'll try this on another 
install and see what happens.

Are you sure your local setup is updated completely?  I tried your 
patch and it works fine with the new code I committed.  When I remove 
that code, it fails as you described.

Nope.  :(



I'm still showing [_configcache] values being set in the registrycache 
after session_start() on line 150 of Registry.php.

For what it's worth, adding a session_write_close() in 
admin/setup/config.php after $registry->clearCache() prevents this 
from happening...but I'm sure that's not really the proper fix ;)

Try what I just committed to HEAD/FRAMEWORK_3.

In framework/Horde/Horde/Registry:



Before line 150, the registrycache variable is empty.  After we start 
the session, it is no longer empty, and contains only the 
[_confCache]. array.

Ok. So far:



In admin/setup/config.php we unset($_SESSION['_registrycache']) after 
the new config file is written to disk.  Checking the value of 
$_SESSION['_registrycache'] at the end of the page verifies it is 
indeed unset when the page is completed.



Now, when we try to load any other page:

In framework/Horde/Horde/Registry.php, in the constructor function for 
Registry, we check if the registrycache is there or not.  Checking the 
value of $_SESSION['registrycache'] at this point shows that it is not 
empty, but only contains the [_confCache] array, and nothing more...so 
the $this->applications variable never gets populated.



For now, just commenting out the line where we unset the session 
variable fixes this...I'll continue to try to track this down, but any 
help in pointing me to a place to look would be appreciated!!



Thanks.

Possibly related to Bug: 3191 and Bug: 3224 - but this happens 
regardless of what combination of language settings you use.  This is 
with HEAD from about 10 minutes ago, all config/ files refreshed, 
framework freshly symlinked etc...



To reproduce:



1) Create a <configspecial> section in any application's conf.xml file 
and create code to handle it in framework/Horde/Horde/Config.php.   
This code should call some arbitrary api function.  I've tested using 
numerous api calls from numerous applications.



2) Reconfigure the application using the 'Setup' interface.



3) The setup page works normally, succesfully calling the api function.



4) Generate the new conf.php file.  If the file is succesfully written 
to disk, the registry loses *all* applications and all attempts to use 
Horde causes a fatal.



5) Either closing the browser or rewriting horde/config/registry.php 
will restore functionality.



I've attached a very simple test patch to demonstrate.



I'll try to track this down, but I'm not promising anything ;)