Upgrade to PHP 7.2 causes session_cache_limiter error

1,165 views
Skip to first unread message

Nuwanda

unread,
Dec 1, 2017, 9:28:41 PM12/1/17
to Fat-Free Framework

This code has been working fine on PHP versions 5.6, 7.0, 7.1:


session_start();

$f3
= Base::instance();


Just upgraded to the newly stable PHPv7.2, and it throws the error:

Internal Server Error

session_cache_limiter(): Cannot change cache limiter when session is active


If I reverse the session call thus:


$f3 = Base::instance();

session_start();


It works fine again. I should be able to call session_start before assigning F3.

base.php has a call to session_cache_limiter('') on line 2257

F3 version 3.6.2-Release

bcosca

unread,
Dec 1, 2017, 11:56:55 PM12/1/17
to f3-fra...@googlegroups.com
Why would you want to start a session before the browser is informed about how it should name a session or how long it should persist a session? Or would you rather blindly trust any server to have the same configuration?

Nuwanda

unread,
Dec 2, 2017, 12:19:17 AM12/2/17
to Fat-Free Framework
The code worked fine in the last three versions of PHP before 7.2.

Why did it work previously and now it doesn't? That's what I'm asking.



bcosca

unread,
Dec 2, 2017, 12:43:27 AM12/2/17
to Fat-Free Framework
Just because you could get away with it before doesn't mean it's legal :)

Nuwanda

unread,
Dec 2, 2017, 12:54:33 AM12/2/17
to Fat-Free Framework
I've seen plenty of code that starts a session before calling F3. It was a genuine question, and I think it's a fair one. Considering you're the developer of F3, that's a pretty flippant answer.

Message has been deleted

bcosca

unread,
Dec 2, 2017, 5:37:09 PM12/2/17
to Fat-Free Framework
What do you propose? A solution that fits your use case but affects performance of apps of everyone else? Checking session state every time the framework is invoked is expensive, moreso if you create a session for all users - logged in or otherwise. Besides, not all apps require a session. Perhaps you should review your process and ask yourself (1) is it necessary to create a session on all routes/pages of your site, and more importantly (2) why override/preempt the framework with a session?

I haven't probably grasped your rationale for a session_start(), so I'm working on the analogy that you insist on some element styling yet you want that style to survive a CSS reset.
Reply all
Reply to author
Forward
0 new messages