PHP Session the PW way at its most basic

[modifiedcontent]

I use regular PHP Session in several conference websites to serve up the correct event content across a few pages; event number $n is set based on user IP location by a script on the homepage and used to display the relevant program on the next page, etc.

It usually works nicely, but often breaks when I change the PHP version or configuration or look at it funny.

At the moment I have the confirmed correct variable for event number $n at the end of homepage, but on the program page I keep getting another $n value even though it's the same session ID as on the homepage - I've tried several ways to unset and destroy the variable, change the location of session_start(); etc., but nothing works. Either way, the code worked fine before I messed with PHP config.

Trying to troubleshoot this I see that PW has its own way to do sessions. Could that explain why my session variable keeps reverting to the wrong one? I have already turned off all caching and compiling as far as I know. The $session API variable / Session class documentation is super confusing to me, because it is all about login and authentication etc.

What is the correct PW way to do this?

Homepage:

session_start();

... //PHP magic

$_SESSION['event_number'] = $n;


Other pages:

session_start();

if (isset($_SESSION['event_number'])) { 
	$n = $_SESSION['event_number'];
} else { 
	$session->redirect('/'); 
};

I guess I have to use things like `$session->set('event_number', $n)`?

I'll fiddle around with that after dinner, but any pointers would be much appreciated.
 

[bernhard]

// home.php
$session->event_number = 123;

// other
if($session->event_number) ...
else $session->redirect('/');

 

[modifiedcontent]

Thanks again @bernhard. Going the PW way, I still see the same problem. Should I still use session_start somewhere?

Apparently one file didn't get included anymore - certain functions 'not found' etc. I had to add `namespace ProcessWire;` to the top of several template files. Is that now required since a recent version? Did something change?

Adding `namespace ProcessWire;` to a bunch of files fixed missing functions errors, but not the sessions problem. I still get the same session ID across pages, but the variable does not get updated to the one set on the homepage.

I guess I am setting the variable within a class/namespace (?!) IPinfo, so it's not available in namespace ProcessWire? Before the IP geolocation there is a line `use ipinfo\ipinfo\IPinfo;`. Does that interfere with namespace? I don't understand that namespace stuff at all. Should I do something to pass the variable between namespaces?

I've tried using this, but then the event_number doesn't get set at all:

	$session->setFor('ProcessWire', 'event_number', $n);

Wrong syntax? Or just wrong?

If the session ID stays constant between pages, why doesn't the session variable? How could I troubleshoot that?

[BitPoet]

4 hours ago, modifiedcontent said:

Apparently one file didn't get included anymore - certain functions 'not found' etc. I had to add `namespace ProcessWire;` to the top of several template files. Is that now required since a recent version?

No, it isn't, unless you explicitly disabled FileCompiler in your config.php. Otherwise, it's usually a sign that the permission for your site/assets/FileCompiler folder are wrong (or even that the web server instance is running with a different user/group id than previously and lacking write access - on shared or cloud hosting, switching PHP versions could also mean switching web server instances).

[modifiedcontent]

Thanks @BitPoet. My sites are on a VPS, not shared or "cloud" instances. What are the correct folder permissions? Is that listed anywhere?

I had double-checked folder permissions/ownership and disabled FileCompiler on every template to fix these problems, which did the trick. I'll re-enable them and see if it has any impact on my current PHP session problem.

With 'Use Compiled File' set to Auto on every template and namespace removed from all template files, everything looks normal, but session still doesn't work - one session ID across pages, but the variable doesn't stay updated. 

When I just manually change the event number in the homepage script, PHP session works fine and that variable does get carried over to the next page:

$session->set( 'event_number', 23 );

This also works:

$n = 15;
$session->set( 'event_number', $n );

But this fails:

... script that produces a valid $n ... 

$session->set( 'event_number', $n );

The $n variable does hold a correct number as far as I can tell. So the problem probably has nothing to do with PHP session or PW, just something dumb in my script.

Does anyone recognize this type of error? What else could I try to troubleshoot?

[Jan Romero]

3 hours ago, modifiedcontent said:

What else could I try to troubleshoot?

Check the actual session storage in /site/assets/sessions/ or, if you’re using the module “Session Handler Database”, in the database table called “sessions”. Sounds like you already know where to find the session ID but for the record it’s in the cookie called “wires” (this is customisable), available in your browser’s dev tools.

You can also check if maybe you’re overwriting the value before reading it on the second page? With a generic term like “session” there’s also always some danger of overriding ProcessWire’s $session variable. Using the Functions API can guard against this.

[BitPoet]

12 hours ago, modifiedcontent said:

What else could I try to troubleshoot?

How about adding a meaningful log output everywhere you read or assign your session variable? The log lets verify in which order those are executed, which page calls they come from, and if there's maybe an execution step you didn't think of. In the more complex developments, I like to make such log output conditional on $config->debug.

<?php namespace ProcessWire;

$session->set( 'event_number', $n );

if($config->debug)
	$log->save('eventnum', "Wrote event number $n to session");

//.......

$evtnum = $session->event_number;

if($config->debug)
	$log->save('eventnum', "Read event number from session: $evtnum");

 

[modifiedcontent]

Thanks @Jan Romero and @BitPoet

My /site/assets/sessions/ folder is empty, except for a .htaccess file. Should there be something there? Do I still have write problems on those folders? I had already triple-checked permission/ownership - what are the correct settings?

Sessions worked fine when I hardcoded the session variable in the script, so probably not related either way. I'll try other things tonight or next weekend and report back...

Quote

... maybe you’re overwriting the value before reading it on the second page ...

Yes, probably... ?

Edit:

I'm still stuck with this. The session variable value event_number is set correctly on homepage, but then reverts to a previous value on the next page. I don't see where it could be overwritten in between - echoing the variable at the end of page 1, top of page 2. 

Where are PW php sessions stored? On the client machine? In "memory" somewhere? Cookie? Should I see files in the /site/assets/sessions/ folder? Could register_globals interfere with how sessions are stored?It does work when I hard-code the event_number value, so session is stored somewhere?

I'll look into the “Session Handler Database” module that @Jan Romero mentioned next...
 

[modifiedcontent]

Trying to install the Session Handler Database module, I get this error that probably explains my problem ? : 

Your PHP has a configuration error with regard to sessions. It is configured to never clean up old session files. Please correct this by adding the following to your /site/config.php file: ini_set('session.gc_probability', 1); 

Unfortunately just adding that to config does not fix my current session script, although the error message on the module is gone.

Where are 'old session files' supposed to be stored? I still see nothing in my /site/assets/sessions/ folder. What are the correct ownership and permission settings for that folder? 

I have installed the Session Handler Database module, but see no change. Am I supposed to adapt my session script to it? 

Under Access in the admin area I now see this:

SESSIONS
The process module assigned to this page does not appear to be installed.


and:


Sessions
This page has no process assigned.

How did that happen? How can I fix it?

[gebeer]

On 1/30/2023 at 6:06 PM, modifiedcontent said:

Where are PW php sessions stored? On the client machine? In "memory" somewhere? Cookie?

Session on the client side are stored in cookies. You can use your browser's dev tools to inspect those.

On 2/3/2023 at 11:07 PM, modifiedcontent said:

SESSIONS
The process module assigned to this page does not appear to be installed.


and:


Sessions
This page has no process assigned.

How did that happen? How can I fix it?

HOw that happened, no idea. To confirm that SessionHandlerDB module is installed you can go to Modules->Core. If you see Session Handler Database listed with a green Settings Button, then it is installed.

In the page tree under Admin->setup there should be a page "Sessions" 

When you edit that page, under Process there needs to be ProcessSessionDB set

Same goes for Admin->Access->Sessions.

If this is the case then you should be able to see the sessions when you go to either Setup->Sessions or Access->Sessions.

The entries there have nothing to do with your session variables.

On 2/3/2023 at 11:07 PM, modifiedcontent said:

Where are 'old session files' supposed to be stored?

If you don't have SessionHandlerDB module installed, they are stored in site/assets/sessions. Also there, your session variables will not be stored.

On 2/3/2023 at 11:07 PM, modifiedcontent said:

I have installed the Session Handler Database module, but see no change. Am I supposed to adapt my session script to it?

No. The storage location of sessions (file system or DB) does not have anything to do with your script.

On 2/3/2023 at 11:07 PM, modifiedcontent said:

What are the correct ownership and permission settings for that folder? 

See my answer in your other thread. On a side note, it would be better to keep this in one thread since it is the same underlying problem. Posting 4 different threads about 1 problem does not help and could be considered as spam.

 

On 1/30/2023 at 6:06 PM, modifiedcontent said:

Sessions worked fine when I hardcoded the session variable in the script, so probably not related either way

This tells me that something with your script might be wrong, not with how PW handles sessions.

[modifiedcontent]

Quote

Posting 4 different threads about 1 problem does not help and could be considered as spam.

Bullshit. I don't know if this is 1 problem; there may be several completely unrelated things going on and I am trying to untangle them. I create threads when I try to solve distinct issues and mostly to keep track of my own findings. I had already acknowledged that my problem may be caused by something dumb in my script, but that is not what this thread is about. 

This thread was about the proper PW way of doing PHP sessions, if there are any differences with regular PHP sessions to watch out for, how and where in PW sessions are stored, etc. @bernhard@BitPoet@Jan Romero had already answered most questions.

The fact that my /site/assets/sessions/ folder is empty and sessions process suddenly had gone missing seems to point to other issues as far as I understand now, so I started another thread about that - or is /site/assets/sessions/ supposed to be empty?  

[gebeer]

17 hours ago, modifiedcontent said:

Bullshit. I don't know if this is 1 problem;

Sorry if I was rude. I apologize. Had a bad day yesterday...

17 hours ago, modifiedcontent said:

The fact that my /site/assets/sessions/ folder is empty and sessions process suddenly had gone missing seems to point to other issues as far as I understand now, so I started another thread about that - or is /site/assets/sessions/ supposed to be empty?

From your other thread about Apache and suExec configuration it seems that most of the session stuff might also be user/permission related.

[modifiedcontent]

Apologies for my rude response, @gebeer. No problem. Hope this week is better for you.

My session stuff is still not fixed after solving the user/permission issues. This thread cleared up most of my PW session questions, so it must be something dumb in my script/templates.