russblau wrote:

I had experienced this same issue occasionally under the 1.4 version, so it may not be a new
bug introduced with 1.5, but it still needs to be addressed.

fred_chessplayer wrote:

Based on a comment by myself and others on the MW 1.5 bug page, the problem has been
confined by several Firefox users, but by no users of Internet Exploder.

I suspect that an equivalent on IE may be repeated browser crashes when pressing Preview
or Save, but can not confirm it.

ilyanep wrote:

Well...I hope you're still going to address the problem, because many wikipedia
users use Firefox (and you can't hang such users out to dry) [end rant] I have
experienced this problem before, so I'm voting for it.

This is unlikely to have anything to do with which browser you use, as it appears to be a server-side
issue with session data being messed up. Switching browsers will appear to resolve the issue because
you're running with a different session cookie, whose storage has not gotten corrupted yet. Clearing
the cookies on the same browser should have the same effect.

(And, hopefully it's been resolved since last night. Please report if it continues.)

eurosnoopy wrote:

I'm getting same problem, Browser IE6

eurosnoopy wrote:

This bug only occurs when logged in. As soon as I am logged out pages save and preview normally.

jamesh wrote:

Also happens in opera, my wiki is attached to a group of hosting servers that save session data to the local disk on each system.

dan.polansky wrote:

I consistently experience this issue in Microsoft Internet Explorer, version
6.0.2800... A page is saved only after I try to save it severa (usually five to
fifteen) times. I have experienced this problem with MediaWiki 1.4.5, and also
after updating to MediaWiki 1.4.9.

Re comment #8: is this actually related to your browser in any way or is it your
server configuration (broken session storage, for instance a misconfigured server
farm such as SourceForge hosting)?

dan.polansky wrote:

Brion, the issue is not related to my browser. I was trying to point out that it
is browser-independent. From the bug report 1819 [1] I understand that this
issue usually relates to the broken session configuration. Indeed, our project
is hosted at SourceForge.

Do I understand it correctly that I should change session.save_path so that it
does not point to /tmp, in LocalSettings.php? Thank you.

[1] http://bugzilla.wikipedia.org/show_bug.cgi?id=1819

dan.polansky wrote:

Addition to comment #10: one user suggests to add the following line to .htaccess file at SourceForge

php_value session.save_path /home/groups/f/f4/f4l/tmp/

I'll check it out; still I wonder how I get rid of old session data stored in /home/groups/f/f4/f4l/tmp/.

dan.polansky wrote:

Closing of my previous comments: I solved the issue by getting the session management of PHP right. For hosting on
SourceForge, advice is given at http://meta.wikimedia.org/wiki/Running_MediaWiki_on_Sourceforge.net. The remark above on

php_value session.save_path /home/groups/f/f4/f4l/tmp/

does not work. From August 2005, it is necessary to store session data in /tmp/persistent/, like
in /tmp/persistent/projectname/sessions. Thank you for the help.

thomas_d_huber wrote:

Have the same problem with 1.4.9 on a SF project, suggestion to store in
/tmp/persistent doesn't work (no more?) as tmp/persisent is read only.
I also tried to add
session_save_path("/home/groups/f/f4/f41/tmp");
into LocalSettings.php after a mkdir of tmp and setting 777 to this directory
without any effort.

Isn't there somebody running succesfully wikimedia for a SF project with advice?

thomas_d_huber wrote:

At least I could fix this problem with additional informations from the pmwiki
pages and I can edit/save wiki pages on souceforge again. Advice on
http://meta.wikimedia.org/wiki/Running_MediaWiki_on_Sourceforge.net was not
clear enough for me.
What I did:

1. used putty to connect as project admin to sourceforge
2. added a session directory in the rw project space mkdir /tmp/persistent/myproject cd /tmp/persistent/myproject/ chmod 755 . mkdir /tmp/persistent/myproject/sessions
3. closed the putty session
4. edit LocalSettings.php right after $IP... line I added a new line with the session path session_save_path('/tmp/persistent/myproject/sessions');

But there is another problem with the image upload for which I couldn't find a
solution. As project webspace is now mounted RO for sourceforge projects and
upload of wiki images is configured to be under the webspace uploading will fail.
Changing configuration in LocalSettings.php in the same way as for sessions with
two additional directories under /tmp/persistent/myproject/ (eg.
/tmp/persistent/myproject/images and /tmp/persistent/myproject/wikifiles/images)
didn't help, the image was uploaded successfully but click to view was showing
an error that the file couldn't be found (although it was existing there). No
idea how to fix this :-(

Does a symbolic link to the images directory work?

thomas_d_huber wrote:

Thought about but I'm not familiar with *nix OS. I can try if somebody can advice...
AFAICT I would need to have first:

1. writable directories under /tmp/persistent/myproject/images and

/tmp/persistent/myproject/wikifiles/images
and then create symbol link for
a. wgUploadPath to ../myproject/wikifiles/images
b. wgUploadDirectory to ../myproject/images
with default configuration of wikimedi LocalSettings.php, right?

So how could I establish the correct symbolic link?
I know this question is not related to mediawiki but anyway may help to find out
the correct setting to run mediawiki in a SF environment and document it.

Something like:

cd /home/groups/m/my/myproject/htdocs/wikifiles
mv images images-bogus # or just delete it
ln -s /tmp/persistent/myproject/images images

thomas_d_huber wrote:

That was the point, Thanks!
Though I had to upload again all image files but I think I had used the wrong
image directory, but now I can say my SF wiki is back with all functions I use.
Thanks again Brion.

drkolb wrote:

I'm still getting this error several times a day on the English Wikipedia and it
happened again just a minute ago. Sometimes, I have to press save 4 or 5 times
before it goes through. I haven't had the edit conflict problem, unless someone
else's edit goes through while I'm stuck with the previews. Thanks

kirsch wrote:

Some background information and a possible solution:

The reminder that php stores session information in some files, typically
located in /tmp, seems to have put me on the right track.

I am running my own mediawiki for collaboration with co-workers. It can be
reached through a web front-end machine that distributes HTTP requests to
several machines for load-balancing and failover purposes. Of course the
machines don't share /tmp. Consequently they don't share the session data.
Depending on how the front-end distributes your "Save page" requests, (my guess
now) the session data gets all messed up.

This scenario fits the following observations:
*The problem appears on wikis hosted by big hosters like sourceforge that most
likely have a similar load-balancing scheme.
*Hitting the "Save page" button repetively sometimes helps --- you have a chance
to end up on the right machine.
*Users not logged in have no problem with this, because they have no session data.

With my limited php knowledge I see only two possible solutions:
#Store the session data in a directory shared by the different back-end servers
(see other comments).
#Convince the provider to bind originating IP-addresses/ports/cookies/machines
(dunno which one applies) for some time (e.g. 30 minutes) to the same backend
machine.

SGBailey wrote:

Happening a lot today from work (laptop/W2000/MSIE) and home (desktop/W98SE/MSIE). V
frustrating. -- SGBailey 2005-10-11

radu.antohi wrote:

(In reply to comment #6)

This bug only occurs when logged in. As soon as I am logged out pages save and

preview normally.

You are right... I'm having the same problem... anybody has a solution for this?
I'm using Firefox... and I need to delete the cookies in order to be able to
save a page. If I login, the save does not work anymore... I need to clear the
cookies and then the save option is working...

Anybody can help?

Thanks,

Does this still occur?

Closing due to inactivity.