Last modified: 2010-12-05 20:16:03 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 T4846, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2846 - Edit not saved
Edit not saved
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
PC Windows XP
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-13 18:03 UTC by Angus
Modified: 2010-12-05 20:16 UTC (History)
4 users (show)

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


Attachments

Description Angus 2005-07-13 18:03:00 UTC
I spent several hours yesterday (across two sessions) on 
http://en.wikipedia.org/wiki/Meanings_of_asteroid_names_%
285001-5500%29 adding identifications which are not there 
today! I know something was said about this feature when 
the wiki software was upgraded, but the problem has not 
been fixed. I would have thought that this would have 
been your number one priority! If the user sees that all 
the time he or she is prepared to put into this exercise 
is going to be vitiated when Save is pressed, then that 
user will have no confidence in the system!

I have noticed this in earlier edits but wasn't 100 
percent sure. Now I am and I am disappointed at the 
failure of the system and of Wiki software people to 
address this obviously major fault!
Comment 1 Antoine "hashar" Musso (WMF) 2005-07-13 18:10:13 UTC
Please give us your username, the time of your edit.
Also give us an example of changes you added to this article.

http://en.wikipedia.org/w/index.php?title=Meanings_of_asteroid_names_%285001-5500%29&diff=18712419&oldid=18693914

I see change by user Eilthireach adding identifications in this article.
Comment 2 Angus 2005-07-26 02:10:21 UTC
I was unable to get back to you on this. It has happened again 
today. At 1530 hrs I edited Meanings of asteroid names 16001-17000 
and the changes I made to nos. 16817 and 16847 were not there when 
I went back in at 1900 hrs. The changes are text additions, giving 
explanations for the names assigned to each asteroid. The 
identifications replace the asterisks which can be seen against any 
entry that does not have an explanation for its designation.
I am user Eilthireach
Comment 4 Angus 2005-07-26 16:34:53 UTC
No. These were my edits, but not the ones that have disappeared. As 
I reported in "Additional comment #2", the edits were to nos. 16817 
and 16847. As usual, I made changes (added identifications) and 
saved the edits, and when I returned three hours later, the edits 
were gone
Comment 5 Brion Vibber 2005-07-26 18:59:11 UTC
Were they in fact saved, or did that display as a page preview?
Comment 6 Angus 2005-07-26 20:36:15 UTC
Thanks for the reply. I do indeed always go through the preview 
stage before saving an edit, and, since there is a prominent 
warning at the top of the Preview page, I would not have left the 
site at that stage.
 If you cannot find the edit in the logfiles, then I can only 
presume that there must have been a glitch in my broadband 
connection. I am just concerned that I am spending a lot of time 
researching these identifications (and, of course, working on other 
articles) and hope that that work is being properly saved. I can 
check on -some- of the articles but don't have time to check -all- 
the edits on -all- of the articles! You have to take it on trust 
that the system works.
Can I have confidence in the system? Has that bug really been 
corrected that we were all warned about when the wiki software was 
upgraded?
Comment 7 Brion Vibber 2005-07-26 21:04:24 UTC
If a page is successfully saved, it will stay saved.

Be aware that a save operation (clicking on the 'save' button) may fail for 
various reasons:
* Edit conflict requiring manual resolution
* Session data expiration requiring confirmation or relogin as a security check
* Database congestion of lock conflict producing a database error
* Other transient error

Can you confirm that none of these occurred -- that you did not receive an 
error message, or a preview, or any other such, but that you were presented 
with a successful save and the version of the page as you wished to leave it?

Can you clarify about "the feature" and "the problem" you speak of? What 
feature is this? What is the problem with it? What does it have to do with last 
month's upgrades? Who "warned" you about it, and what specifically was this 
warning?

Please be as specific as possible in documenting this problem.
Comment 8 Dennis C. During 2007-09-04 23:07:54 UTC
I have today twice lost edits to [[Time management]], most recently at 18:30EDT. Earlier incident around 14:00EDT. The changes included text and numerous tags. 

I am willing to play along for a while, but if there is no resolution I'm not going to be an active contributor to Wikipedia. Is there some practice I can follow that will eliminate the risk? It appears that I will have to do any high-volume work off-line and cut-and-paste it in. Can I count on that working ?
Comment 9 Brion Vibber 2007-09-05 15:03:51 UTC
I can't find any sign of edits at those times in the database. My guess would be that some glitch is causing the edit to fail to save properly, but the user interface still is redirecting you to the final page view, hiding the error message.

If you don't look closely enough to see that your change didn't get saved, it's hard to tell anything bad happened.

Unfortunately our database error logs are currently stuffed up with an unrelated problem so I'm limited in my diagnostic tools. :(
Comment 10 Roan Kattouw 2007-09-05 17:01:19 UTC
(In reply to comment #9)
> I can't find any sign of edits at those times in the database. My guess would
> be that some glitch is causing the edit to fail to save properly, but the user
> interface still is redirecting you to the final page view, hiding the error
> message.

When writing the ApiRollback module, I discovered that Article::rollback() ignores certain obscure errors. This case may be similar.
Comment 11 Chad H. 2009-09-02 02:01:24 UTC
Is this still an issue?
Comment 12 DieBuche 2010-12-05 20:16:03 UTC
doesn't seem so

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


Navigation
Links