The original populateParentId.php script is sadly no longer available as of MediaWiki 1.36. Prior to its deletion, it used to populate rev_parent_id. However, deleted revisions from MediaWiki 1.18 or earlier could still be missing parent IDs, which, for example, caused https://en.wikipedia.org/w/index.php?title=EasyTag&oldid=172231225 (a redirect from a move) to not have rev_parent_id 0, but instead rev_parent_id 168548799. To avoid this and make sure that future undeletions of revisions that were deleted in MediaWiki 1.18 or earlier work the same as for revisions deleted in newer MediaWiki versions (1.19 or later), we should create a populateArchiveParentId.php script that would populate missing parent IDs (i.e., the ar_parent_id column) for rows in the archive table, similar to what populateParentId.php did with the revision rable.
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T223342 Create backlog extension for fixing rev_parent_id and ar_parent_id | ||
| Open | Feature | None | T312679 Create populateArchiveParentId.php script |
Event Timeline
Perhaps ar_parent_id could be populated for rows with ar_page_id set, such a script could check both the revision and archive tables to find the parent rev ID. If ar_page_id is NULL, I suppose it could guess passed on the archive table (title,time) alone.
I don't fully understand how https://en.wikipedia.org/w/index.php?title=EasyTag&oldid=172231225 relates to this. Did the 8 July 2022 undeletion encounter a null ar_parent_id and then RevisionStore::insertRevisionOn(), via UndeletePage, used getPreviousRevisionId() to guess the previous revision from page_id,timestamp (effectively seeing a now-restored prior revision)? Logically, at the time of that redirect creation revision, the parent ID was 0 since prior (single revision?) redirect was deleted, but ar_parent_id was not around in 2007, so when ar_parent_id was added it was null for that row. If we made a script, I'm not sure how it would be smart enough to use 0 instead of some previous deleted redirect revision. It seems like a backfill script could just make the same mistakes as what UndeletePage ended up doing. Maybe ar_page_id could be used, for rows where it's set, to avoid setting the ar_parent_id to a revision from what was logically a different page (but under the same title)...
See also:
- https://en.wikipedia.org/w/index.php?title=Special:Log&page=EasyTag
- https://en.wikipedia.org/w/index.php?title=Special:Log&page=EasyTAG
Also tagging @Ladsgroup