Last modified: 2010-05-15 15:38:25 UTC
instead of saving, after clicking save, only the preview comes up. some users have tried up to 10x until wikipedia accepted the save-command. discussion for example: [[de:wikipedia:Fragen zur Wikipedia#dampfablass]] I was told, this bug is known, but I couldnt find it in here.
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.
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.
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.)
I'm getting same problem, Browser IE6
This bug only occurs when logged in. As soon as I am logged out pages save and preview normally.
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.
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)?
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
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/.
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.
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?
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?
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
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.
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
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.
Happening a lot today from work (laptop/W2000/MSIE) and home (desktop/W98SE/MSIE). V frustrating. -- SGBailey 2005-10-11
(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.
