Last modified: 2010-05-15 15:37:50 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 T4984, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2984 - Selective undeletion jumbles latest article.
Selective undeletion jumbles latest article.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.5.x
All All
: Low minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-27 22:20 UTC by Tony Sidaway
Modified: 2010-05-15 15:37 UTC (History)
1 user (show)

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


Attachments
Test on English Wikipedia: 1 Create redlink (125.85 KB, image/png)
2005-07-27 23:03 UTC, Tony Sidaway
Details
Test on English Wikipedia: 2 Create first version (128.10 KB, image/png)
2005-07-27 23:04 UTC, Tony Sidaway
Details
Test on English Wikipedia: 3 Create second version (127.94 KB, image/png)
2005-07-27 23:05 UTC, Tony Sidaway
Details
Test on English Wikipedia: 4 Delete page (139.73 KB, image/png)
2005-07-27 23:06 UTC, Tony Sidaway
Details
Test on English Wikipedia: 5 Restore original version only (130.60 KB, image/png)
2005-07-27 23:07 UTC, Tony Sidaway
Details
Test on English Wikipedia: 6 Both versions are in the history list (135.77 KB, image/png)
2005-07-27 23:07 UTC, Tony Sidaway
Details
Test on English Wikipedia: 7 Clicking the latest version gives error message (145.38 KB, image/png)
2005-07-27 23:08 UTC, Tony Sidaway
Details

Description Tony Sidaway 2005-07-27 22:20:55 UTC
This has been confirmed on live Wikipedia. (27 Jul, 2005).

Create an article.
Edit so you have two versions.
Delete all versions.
Undelete the original version only.
Undelete the latest version.

The original version is restored correctly but the latest version vanishes.

In a test on a modified 1.4.7 database, the version was deleted from archive but
was restored to old instead of  cur. The version in cur should have been moved
to old and the restored version should have been moved to cur.
Comment 1 Tony Sidaway 2005-07-27 23:03:39 UTC
Created attachment 744 [details]
Test on English Wikipedia: 1 Create redlink
Comment 2 Tony Sidaway 2005-07-27 23:04:37 UTC
Created attachment 745 [details]
Test on English Wikipedia: 2 Create first version
Comment 3 Tony Sidaway 2005-07-27 23:05:26 UTC
Created attachment 746 [details]
Test on English Wikipedia: 3 Create second version
Comment 4 Tony Sidaway 2005-07-27 23:06:17 UTC
Created attachment 747 [details]
Test on English Wikipedia: 4 Delete page
Comment 5 Tony Sidaway 2005-07-27 23:07:03 UTC
Created attachment 748 [details]
Test on English Wikipedia: 5 Restore original version only
Comment 6 Tony Sidaway 2005-07-27 23:07:51 UTC
Created attachment 749 [details]
Test on English Wikipedia: 6 Both versions are in the history list
Comment 7 Tony Sidaway 2005-07-27 23:08:51 UTC
Created attachment 750 [details]
Test on English Wikipedia: 7 Clicking the latest version gives error message
Comment 8 Tony Sidaway 2005-07-28 04:40:53 UTC
The behavior above was largely due to buggy caching. Turning off caching in
preferences, I was able to see the history correctly restore the latest deleted
version. However the older version was still displayed as the latest version,
even though the page history correctly showed the newer version and gave full
access to it.

From IRC:

	Tony_Sidaway	A lot of the bug I was seeing before was just page caching.
	Tony_Sidaway	I still get a problem though. I'll update the bug report.
	Okay, two bugs. (1) page caching is a heap of poo when you do this kind of
thing. (2) now I disabled caching and then undeleted the newer version, my older
version is stil being displayed as the latest, although the hisitory list is okay.
	So it goes like this: Create A, edit to make B. Delete article, A and B.
Undelete A only. Undelete B. Now the history is correct but A instead of B is
displayed as the latest version (and it doesn't seem to be browser caching either).
	And it's not by ISP's proxy, this is over my own intranet, direct SSL
connection on the LAN.
Comment 9 Brion Vibber 2005-07-28 16:11:19 UTC
Before we go into this, let me first detail the changes from 1.4 to 1.5:
* All versions including the current version have a revision id number.
* When a page is deleted, the revision number is stored in the archive table.
* When those revisions are restored, the original revision number is retained.

Additionally note:
* When a page is restored when there is a page already present, the 'current version' marker is not necessarily 
updated. All revisions are present but the 'current' one may still be what was previously there.
* When a page is restored, the page_touched cache marker is not necessarily updated, so the history view may be 
cached.

Can you confirm that, given the caveats above about display oddities, the selected revisions are all restored?
If so, this report can be closed. Open new bug reports about the cache issue if there's not already one.
Comment 10 Tony Sidaway 2005-07-28 17:27:50 UTC
I agree that much of the initial behavior was due to problems with page caching,
and I'm changing this bug because I see no evidence that data is lost in either
HEAD or 1.4.7.

Briefly, the problem I see now is that page.page_latest is not being updated in
1.5 (I'm testing on a branch I made at the weekend) and in 1.4.7 the problem is
that the later version is restored to the "old" table instead of displacing the
earlier version in "cur".  The effect in both cases is that the older version of
the page is regarded as current.

In 1.5, the history display is in the correct order by the current version is
the older one.

In 1.4.7, the history display is garbled, with the older version appearing above
the newer one.

This behavior may or may not be considered a bug--it's likely to confuse a lot
of editors, but is not likely to be encountered very often.  In any case it is
not urgent because it can be worked around by normal editing.  Rather than
completely close it I'm marking it as minor severity, low priority.

I'll review the bug report history for caching and whatnot and may submit a new
bug report or augment an existing one to cover caching behavior.
Comment 11 Brion Vibber 2006-01-22 04:22:33 UTC
Restored bug from flood attack.
Comment 12 Aaron Schulz 2007-05-17 03:17:22 UTC
Done in r21989.

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


Navigation
Links