Last modified: 2010-05-15 15:38:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4603, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2603 - preview instead of save
preview instead of save
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Normal normal with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-06-29 09:31 UTC by WikiWichtel
Modified: 2010-05-15 15:38 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description WikiWichtel 2005-06-29 09:31:30 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.
Comment 1 Russell Blau 2005-06-30 13:15:19 UTC
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.
Comment 2 Fred Chess 2005-07-01 06:54:33 UTC
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.
Comment 3 Ilyanep 2005-07-01 17:40:42 UTC
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.
Comment 4 Brion Vibber 2005-07-01 22:41:05 UTC
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.)
Comment 5 James Jones 2005-07-02 17:16:03 UTC
I'm getting same problem, Browser IE6
Comment 6 James Jones 2005-07-03 05:26:35 UTC
This bug only occurs when logged in. As soon as I am logged out pages save and preview normally.

Comment 7 James Hamilton 2005-07-07 18:23:53 UTC
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.
Comment 8 Daniel Polansky 2005-09-07 18:58:27 UTC
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.
Comment 9 Brion Vibber 2005-09-07 19:15:04 UTC
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)?
Comment 10 Daniel Polansky 2005-09-08 16:35:37 UTC
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.

Comment 11 Daniel Polansky 2005-09-08 17:58:24 UTC
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/.
Comment 12 Daniel Polansky 2005-09-08 19:23:27 UTC
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 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.
Comment 13 T.Huber 2005-09-14 23:02:49 UTC
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 
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?
Comment 14 T.Huber 2005-09-17 13:47:04 UTC
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 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
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 :-(
Comment 15 Brion Vibber 2005-09-18 00:58:34 UTC
Does a symbolic link to the images directory work?
Comment 16 T.Huber 2005-09-18 01:22:37 UTC
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
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.
Comment 17 Brion Vibber 2005-09-18 01:32:38 UTC
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
Comment 18 T.Huber 2005-09-19 06:01:33 UTC
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.
Comment 19 Kevin 2005-10-10 16:19:28 UTC
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
Comment 20 Harald Kirsch 2005-10-11 14:27:51 UTC
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
Comment 21 SGBailey 2005-10-11 17:56:30 UTC
Happening a lot today from work (laptop/W2000/MSIE) and home (desktop/W98SE/MSIE). V 
frustrating. -- SGBailey 2005-10-11
Comment 22 Radu Antohi 2006-02-27 19:58:02 UTC
(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?

Comment 23 Aaron Schulz 2008-10-12 17:13:53 UTC
Does this still occur?
Comment 24 Niklas Laxström 2009-07-29 18:07:42 UTC
Closing due to inactivity.

Note You need to log in before you can comment on or make changes to this bug.