Silverstripe Session not persisting, unless /admin visited

3
votes

To replicate:

Fresh install. Place the following in Page::init().

var_dump(Session::get_all()); Session::set('testVariable', 'testValue');

Visit a page on the site, without logging in and WITHOUT visiting /admin.

The expected result of this (after loading the page twice) would be to see a dump of session data containing testVariable => testValue

Instead it seems that any data stored in the session does not persist between requests. Unless /admin has been visited. Visit /admin, then do the check again...

So something happens when /admin is visited that kicks Session into persisting.

This does not seem to be an issue on all hosting environments... however, 3/4 that we have tested on do have this issue. Two of these are running PHP 5.4, the other two PHP 5.6.

This does not seem to be an issue specific to any SS version, we've tested 3.0.5, 3.2, 3.4.0

I've submitted an issue against silverstripe-framework on github, but any insights would be valuable as we have a site in the wild that is broken because of this, any clues/fix/patch/hack/workaround would be great.

2
silverstripe
Would these explain the issue stackoverflow.com/questions/21911292/… and silverstripe.org/community/forums/general-questions/show/39118 .. Probably not entirely as sessions should def be saved for nonlogged in users also.. But does calling save help? - Olli Tyynelä
The request completes so the issue is not related to the issues raised in those threads. Calling Session::save() doesn't help. - LiveSource
That is really odd, I've tried the scenario and it works just as I would expect - i.e. I dont' get the error. One last thing I'd add to the suggestions is to ensure the session is started with... Session::start(); - Barry
Thanks @Barry Placing Session::start(); in mysite/_config.php does the trick. Also session_start() works but only if called a bit further down the line ie. in Page_Controller::init(). Would still be good to know what the underlying issue is but this is a good workaround for now - LiveSource
@SheaDawson I've added that as an answer, as I couldn't reproduce it I'd have to guess it was some other code interfering. Did you do this on a clean install - Barry

2 Answers

1
votes

Adding Session::start(); before the other session calls works.

0
votes

Try Session::save() after Session::set().