When loading a page (abc) I call a snippet that assigns some values to $_SESSION. When loading subsequent pages (xyz) I call snippets that use the values in $_SESSION that were assigned by the snippet called from abc. This fails as the values no longer exist in $_SESSION.
As part of the debugging, after assigning to $_SESSION I also write info to a system log to show the keys of $_SESSION. The values I assigned are there as expected as well as modx.user.0.resourceGroups and modx.user.0.attributes. When trying to use the values I expect to find in $_SESSION I again write the keys to my system log. This time the only keys reported are modx.user.0.resourceGroups and modx.user.0.attributes. It seems that session_start() is being run somewhere without my knowledge.
The page named abc in this description was the page defined as the site_start page. Clutching at straws I reasoned that session_start() was somehow being called when the site_start page was loaded. (I have no reason to believe this.) I created a new page and made that the site_start page. After being displayed it plays no further part in this scenario. However this did not change the behaviour described above.
Further testing:
This problems occurs on a desktop computer using Windows 10 and Google Chrome Version 99.0.4844.82 (Official Build) (64-bit). But on an Android device the problem does not occur. (Android version 10. Chrome version 99.0.4844.73). When testing on the Android device the keys in $_SESSION include modx.user.contextTokens (in addition to the other two mentioned) which is not the case when testing from the desktop computer.
Have you checked if the session cookie exists in the browser?
(If you open the browsers’s developer tools (F12), the cookies should be listed in the tab “Storage” or maybe under “Application”.)
In PHP, every single request has to call session_start() to get access to the data stored in the session, so you’re likely barking up the wrong tree trying to debug that. MODX will call that automatically for you.
It does sound like the session cookie isn’t sticking and a fresh session is created for each request. Perhaps you’ve marked session cookies as secure (by enabling the session_cookie_secure system setting) but are browsing the site on http instead of https, or maybe there’s a hardcoded session_cookie_domain set that doesn’t match?
It’s worthwhile to try it in an incognito/private window to make sure the problem is not related to existing cookies - if it does work in an incognito/private window, clearing your cookies should also fix it in the main browser.
Another way to check (in addition to what Harry posted) is to open developer tools on the Network tab, refresh the page, and inspect the response headers. There’s like a Set-Cookie header there: what flags, path, and domain does that include?
Thanks Mark and Harry, I appreciate your suggestions.
I have checked the settings you suggested and have attached screenshots of the settings I think you mean. Do they show anything untoward? (They don’t mean anything obvious to me.) The cookie settings were “block third-party cookies in incognito.” I changed it to “allow all cookies” and then loaded the website in incognito. The problem remains as before.
Does the absence of the 3rd key I mentioned in my description ( modx.user.contextTokens) mean anything?
Ooops! I had included 3 images but this interface allows new users to include only 1. I’ll have to try to a attached the other two separately.
I was referring to the settings in MODX, not in your browser.
That just means you’re logged in (if not in the frontend, then possibly in the manager). In the other brower you’re likely just browsing anonymously.
That last screenshot doesn’t show the PHPSESSID cookie being set and suggests you’re on the ogs.google.com domain? I doubt that’s your MODX site, is it?
Correct. On the desktop computer I have the modx manager open.
The modx site is www.piecework.co.za if you would like to try it. The landing page is temp page I mentioned which I will reset once I have resolved the problem. To get to the page that demonstrates the issue you can use www.piecework.co.za/?id=2 . The buttons should take you to other pages, but because of the logic which kicks in if the values in $_SESSION are not found, this landing page is shown instead.
Session_cookie_secure is set to No
Session_cookie_domain is set to blank.
….Another way to check (in addition to what Harry posted) is to open developer tools on the Network tab, refresh the page, and inspect the response headers. There’s like a Set-Cookie header there: what flags, path, and domain does that include?..
I don’t see what I think I should be seeing. Did I go to the wrong place again?
I have cleared cache and cookies and the pages are working as expected. I’ll have to leave it there for now although I am not fully satisfied that I understand why the error occurred and what to do to prevent it from happening again. Anyway, thanks for your help.
