Tickets :: Comment on [#3304] Registry losing applications after api calls from configuration screens

* Your Email Address
* Spam protection	Enter the letters below: .__ . .. ..__..__ \| \\|__\|\| \|\| \|[__) \|__/\| \|\|__\|\|__\\|
Comment	> 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...
Attachment
Watch this ticket

Saved Queries