I've searched the forum and google and was surprised to find nothing of help. This is the same problem as I reported earlier in this post

Basically I transferred my site from the development server to the production one and now sessions seem to be messed up. Seven modules all create and access the regular session record in the xoops_session table. The other three modules create and use a second session record against the same IP address. In these three modules when logged in the user login block gets displayed as if the user was not logged in, however, if you click login you get taken to you profile page.

I have moved this site to three different servers without issue. It seems that the fourth one's a dud. I don't know enough about XOOPS sessions to trouble shoot this further and so I'm baffled. Could this be something to do with register_globals or some other php.ini setting?

Please share your ideas as these may help me to form a different search phrase for google.

Rob

I've heard that emptying xoops_sessions table can fix things sometimes.

Quote:

I heard the same and tried that already. The dual sessions are duely recreated. Hmmmm

Hmmm here's something else strange. When I enter one of the modules directly by url/modules/module-name it tells me "Sorry, you don't have the permission ... yada yada" and then lets me in anyway. The group and module permissions say that I should be allowed in. I'm picking that this is somehow related to the session issue above. I think it must be something to do with a global variable that is either not available or available when it shouldn't be.

Using a .htaccess causes a server error. I'll try to toggle register_globals off at run time and see if that helps.

Rob

One of the affected modules is extcal. If I browse tohttp://site-url/modules/extcal a new session is started, however, when to browse back to a system page or an unaffected module then the original session gets picked up.

Okay here's something very odd. If I browse tohttp://site-url/modules/extcal/index.php then everything works as normal with the original session id. In both cases I get redirected to calendar.php which suggests that index.php is in fact being executed in both cases but the context is somehow different.

Now I can hardcode the index.php part in, and I will, but why are these modules behaving this way and why only these modules? I'm guessing that the DirectoryIndex statement on the production server is what's different (can't check right now) and not a php variable afterall.

Rob

The snippet above is part of theme.html and is used twice to draw a menubar at the top and bottom of every page. When I went to hard code the index.html in I found that the two affected modules (extcal, wfsection) lacked a terminating / in their urls. Simply inserting the / fixed the problem completely.

I still can't get my head around quite why this was a problem but for now all is good.

Rob