Hello again folks,
I'm still fighting a battle with lost session data.
It seems like I'm getting closer--I have my session.save_path in a custom php.ini file pointing correctly to a directory I have full access too, and I even see files being written there, but they are empty (0 bytes). The end result is I'm still not able to edit pages while logged in. Mediawiki continues to report a loss of the session data. Another php site we have on the same server space does show session data in it's session file, so I think it's something with the mediawiki configuration.
The files being written are in the format "sess_lotsofrandomnumbersandletters" , and permissions are set to -re------ (600). Is that how they should look?
Complete symptoms: I can only edit files if I'm NOT logged in. I can only upload files if I am logged in. I can only stay logged in while changing pages if I check the "Remember me on this computer" box while logging in. In other words, in appears that no session data is being saved on the server, and/or being retrieved, in spite of the session files being written in the directory specified.
What else can I be missing that would be causing a continuous loss of session data?
This is a fresh install of version 1.10.0 running under PHP Version 5.1.0RC1, The Server API is listed as CGI, if I am stating that correctly, and this is all running on Linux. I'm using a custom php.ini file I can teak to override the defaults. If it helps to figure out the issue, here is a link to pi.php file to see the environment: http://americanpipemakers.info/mediawiki/pi.php
I'm a noob with all this. I love mediawiki, and think it's perfect for my application, but I obviously need to get this nailed down before I can launch the project.
Thanks for trying to help, Scott
Hi Scott,
On 7/1/07, Scott E. Thile sethile.pipes@gmail.com wrote:
What else can I be missing that would be causing a continuous loss of session data?
Are you running a MEMCACHED server?
Hello Daniel,
You asked:
Are you running a MEMCACHED server?
Not that I'm aware of, at least certainly not I set up myself, but this is running on a site I have hosted with phpwebhosting, and it's a little hard to figure out exactly how the server is configured. It is running under PHP-CGI, which I gather runs it under my user name. and I therefore have a custom php.ini file, which is about my only way to tweak it.
I'm about at the end of my wits (didn't have many to start with ;)
It seems very odd that the session data files would be written but have no data in them.
Any ideas? Anyone?
Thanks, Scott
On 01/07/07, Scott Thile sethile.pipes@gmail.com wrote:
Not that I'm aware of, at least certainly not I set up myself, but this is running on a site I have hosted with phpwebhosting, and it's a little hard to figure out exactly how the server is configured. It is running under PHP-CGI, which I gather runs it under my user name. and I therefore have a custom php.ini file, which is about my only way to tweak it.
If you're not aware of it, then you're not using it; memcached requires specific configuration during MediaWiki installation.
Use of memcached would not, in itself, cause session loss problems unless memcached was used to store session data, which is also not the default case.
Rob Church
If you're not aware of it, then you're not using it; memcached requires specific configuration during MediaWiki installation.
Use of memcached would not, in itself, cause session loss problems unless memcached was used to store session data, which is also not the default case.
Thanks Rob! That's a relief... I wonder what is?
Scott
Here's a clue that indicates this is a mediawiki configuration issue, and not the php set up on my host.
We also have a Joomla installation that saves session data (for administrator access to the back end). That's working, and it's making files with session data in them in the same new folder and path I set up.
The Joomla site was also working before I made this path change too. No doubt before the path change the mediawiki session files were being written into the servers /tmp folder, but they were empty. The only change is this is all happening in my server area where I can see what's going on.
So, why would mediwiki be making session files and not writing to them while Joomla can, even though it's using the same php.ini settings?
Any help with this would be greatly appreciated. Thanks, Scott
Scott E. Thile wrote:
This is a fresh install of version 1.10.0 running under PHP Version 5.1.0RC1, The Server API is listed as CGI, if I am stating that correctly, and this is all running on Linux. I'm using a custom php.ini file I can teak to override the defaults. If it helps to figure out the issue, here is a link to pi.php file to see the environment: http://americanpipemakers.info/mediawiki/pi.php
Have you tried upgrading to a stable release of PHP? PHP is buggy at the best of times, but the release candidates are often badly broken.
I know it's working for you with other applications, but that doesn't mean it's MediaWiki's fault. There might be something different about the way we call the session handling functions, which is perfectly valid as documented but broken in 5.1.0RC1.
-- Tim Starling
It worked!
Have you tried upgrading to a stable release of PHP? PHP is buggy at the best of times, but the release candidates are often badly broken.
I know it's working for you with other applications, but that doesn't mean it's MediaWiki's fault. There might be something different about the way we call the session handling functions, which is perfectly valid as documented but broken in 5.1.0RC1.
Thanks Tim! You're right!!! My wiki finally works, and it was due to the upgrading the PHP RC version the host was running. Now happily working away with version 5.2.0.
Thanks very much for tip. It was exactly what I needed. Took nearly forever to get the hosting co to do the upgrade, but they finally did this evening sometime.
I really appreciate the help here folks.
All the best, Scott
On 06/07/07, Scott Thile sethile.pipes@gmail.com wrote:
Thanks very much for tip. It was exactly what I needed. Took nearly forever to get the hosting co to do the upgrade, but they finally did this evening sometime.
Hmm, the normal problem is getting hosting companies to upgrade PHP in the first place - I don't think their language actually supports the phrase "release candidate"...
Rob Church
mediawiki-l@lists.wikimedia.org