Page MenuHomePhabricator

When new pages are created (by Special:Undelete or other means), the page_id should be set to highest archive.ar_page_id associated with that namespace and title
Closed, DeclinedPublic

Description

When possible, Special:Undelete should use the same page_id that is in archive.page_id. Recreated pages should also use the page_id stored in archive.page_id.

Sample cases:

#1 (Simple case): A page is deleted and then undeleted. This presents no complications.

#2 (Simple case): A page is deleted, then recreated, then deleted, and then all the revisions are restored. Since the same page_id stored in archive.ar_page_id was used for the re-creation, all the deleted revisions will have the same archive.page_id and will be restored to it.

#3 (Less simple case): There are a bunch of archive rows with different ar_page_id with the same ar_namespace and ar_title from the legacy system (i.e. what we currently use). Any page recreations or undeletions should probably use the highest ar_page_id with that namespace and title.

#4 (Less simple case): A page is deleted, then another page is moved to that same page namespace and title, and then the deleted revisions are restored into it. They will have to be restored to the new page ID. Maybe this straight-up shouldn't be allowed.

#5 (Less simple case): Page "foo" (page_id 1) is deleted, then another page "foo" (page_id 1) is recreated and moved to "bar", then another page "foo" (page_id 2) is created, then the deleted revisions are restored. They will have to be restored to page_id 2 because bar was recreated under page_id 1.

In cases #3, #4 and #5, it won't always be possible to restore all of the revisions to the same page_id that's in the ar_page_id, but this system would keep page_id and rev_page consistent over deletions, recreations, and restorations better than our current system does.

Of course, bug 11402's being fixed would render some of this moot. But it illustrates some of the challenges involved in keep page_id consistently consistent.


Version: 1.23.0
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=26123
https://bugzilla.wikimedia.org/show_bug.cgi?id=54398

Details

Reference
bz58986

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:28 AM
bzimport set Reference to bz58986.
bzimport added a subscriber: Unknown Object (MLST).

In case #4, what I had in mind by "this shouldn't be allowed" is that it might be required to restore them to a different page title that doesn't collide, and then merge the revisions in a separate action.

In case #5, maybe those deleted revisions from page_id 1 should stay associated with the "bar" page. Maybe in SpecialUndelete.php, the JOIN should be done by page_id rather than by page_namespace and page_title.

How is this bug not a duplicate of bug 26123?

(In reply to comment #3)

How is this bug not a duplicate of bug 26123?

Its scope is broader than 26123's, but there is indeed some overlap. Thanks for noting that.

GTrang subscribed.

T28123 was already fixed at the beginning of this year. Also, if a deleted page is recreated, its history should be completely independent from the deleted history in some cases. You can move A to B without redirect, undelete A, move A to C without redirect, and B to A without redirect to separate out deleted revisions to another title C. With no further comments, I decline this task.