note 87245 deleted from function.session-set-save-handler by drak

Note Submitter: e dot sand at elisand dot com ---- Here's a few useful tips when working with custom session handlers (and sessions in general - with PHP 5.2.x)... 1) Setting session_set_save_handler() automatically sets the ini setting session.save_handler to 'user' for you - no need to do it yourself. 2) You may in fact not need to set up a __destruct() or use register_shutdown_function() to write your session data if using classes/objects. My testing with 5.2.x shows that my session data is safely saved without the need of either. I am unsure if PHP internals have changed to "fix" this and documents just aren't updated with that info, or if perhaps I haven't yet hit a scenario that would trigger this problem. 3) It's stated a few places - but just to re-iterate: you cannot serialize internal PHP objects. This means if you have a class that extends an internal class (for example, a class that extends PDO for db functions), you will not be able to save an instance of your class in a session variable. Worst off, you will get a very vague error message about it, saying an unknown exception was thrown and it won't know from where. The solution is for any class that has to be serialized, don't extend internal classes, instead have them set up an instance of that object internally via __construct() or something, and then use __sleep() and __wakeup() hooks to export/reconfigure your class variables/resources. 4) It appears that since PHP 4.x or somewhere, the seralization of data that takes place for sessions changed. It used to export human readable text much like serialize() does, however it appears that now the session data is further encoded - quite possibly to hinder session data tampering on the local filesystem. Just mentioning this if you used to view session data to see what was being saved.