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

ID: 27555 Comment by: ondraster at gmail dot com 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: 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! Previous Comments: ------------------------------------------------------------------------ [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... ------------------------------------------------------------------------ [2006-01-19 00:51:20] graeme at druknet dot bt This is certainly entering the realms of a bug now with 5.1.2. If I unset an object which has destruct that tries to update the session variable then the output is truncated. Proper headers are not set. If I don't unset then I get the following unhelpful error message: Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0 ------------------------------------------------------------------------ [2005-11-29 11:36:55] php at mike2k dot com This is still a bug. I just upgraded to PHP 5.1.1, using a custom session handler with mysqli, and this is a problem. It appears this is a workaround, albeit I don't think this should be required to function as it did before. I use procedural code, and not object oriented code, so having __destruct handlers do not help me. register_shutdown_function('session_write_close'); Here's my [very simple] session handler. Note db_query() is a simple wrapper for mysqli_query() and handles all the connection details internally. function session_close() { return true; } function session_die($id) { db_query("DELETE FROM session WHERE ID='$id'"); return true; } function session_gc($maxlifetime) { return true; } function session_open($path,$name) { return true; } function session_read($id) { $dchk = db_query("SELECT data FROM session WHERE ID='$id'"); if(db_numrows($dchk) == 1) { if(!isset($_SESSION['row'])) { $_SESSION['row'] = 1; } list($data) = db_rows($dchk); return base64_decode($data); } else { return ""; } db_free($dchk); return true; } function session_write($id,$data) { global $visitor; $data = base64_encode($data); if(!isset($_SESSION['row'])) { db_query("INSERT IGNORE INTO session (ID,data,accessed) VALUES('$id','$data',UNIX_TIMESTAMP(NOW()))"); } else { db_query("UPDATE session SET data='$data',accessed=UNIX_TIMESTAMP(NOW()) WHERE ID='$id'"); } return true; } (fyi: I have a cronjob that does garbage collection based on the "accessed" column) I still think this is a bug, I don't see why this was changed. ------------------------------------------------------------------------ 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