#27555 [Com]: Unable to modify $_SESSION from __destruct()

From: Date: Tue, 20 Oct 2009 19:44:37 +0000
Subject: #27555 [Com]: Unable to modify $_SESSION from __destruct()
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-2982@lists.php.net to get a copy of this message
ID: 27555 Comment by: gabriel at gabrielharrison dot co dot uk Reported By: jaanus at heeringson dot com Status: No Feedback Bug Type: Documentation problem Operating System: Linux 2.4.24 PHP Version: 5CVS-2004-03-10 (dev) Assigned To: helly New Comment: Hi, I can not find anything in the documentation about this. Was it added or was the feature changed in newer versions? Thanks, Gabriel Previous Comments: ------------------------------------------------------------------------ [2008-03-07 21:54:57] ondraster at gmail dot com Sorry for my last comment, I had bad PHP version in httpd.conf. I feel ashamed... ------------------------------------------------------------------------ [2008-03-07 21:23:18] ondraster at gmail dot com This bug (unwanted feature maybe?) is really annoying. For example I want, when __destroy, write to session last visited address. This bug (feature) has been submitted in year 2004 and still has no fix or there has not been any reason why are all modules unloaded before __destroy is called? When running __destroy, script is still running so there's no reason why this function shouldn't have all resources. I don't know, why this is classified as Documentation problem, when it is clearly BUG! ------------------------------------------------------------------------ [2006-12-06 22:50:26] php at kieran dot ca This bug seems to be affecting the DOM functions as well. <code> class someNode extends DOMNode{ function __destruct() { echo "now I have ".$this->attributes->length." attribute(s)"; } } $x = new someNode('nodename'); $x->setAttribute('bob','frank'); echo "I have ".$x->attributes->length." attributes"; // outputs "I have 1 attribute(s)" unset($x); // outputs "now I have attribute(s)" </code> This behaviour also seems to affect the __construct function as well. ------------------------------------------------------------------------ [2006-10-13 09:20:45] spidgorny at gmail dot com I'm writing because of Status: No feedback. In my opinion this is not strictly a bug, but a very unconvenient undocumented feature. The best is to fix it, because in some cases it would be nice to save to the session some of the properties of the class in the destructor. Otherwise it must be documented in a way that it's flashing and really stands-out, because this behaviour is unlogical. P.S. Spent few days to debug it out in a large application. ------------------------------------------------------------------------ [2006-09-22 18:39:34] slawo at csuk-solutions dot net I strugled for hours today looking for the souce of the problems within our current application, finally I noticed that some objects did not apear in the sessions variable as they should. Finaly the conclusion is we relied on an inconsistent behavior in PHP. Linux Mandrake 10 php 5.1 Will this bug be seen to soon? This is not a bug, this is a feature... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27555 -- Edit this bug report at http://bugs.php.net/?id=27555&edit=1

« previous php.doc.bugs (#2982) next »