Sun, Jun 23
Sat, Jun 22
Fri, Jun 21
This might be caused by T221980. It seems that in general, neither categorylinks table rows nor recentchanges entries are correctly deleted when a page is deleted to make way for a move from another title.
Fri, Jun 14
Tue, Jun 11
The following example shows that for imported revisions, rev_parent_id might require fixing on both the source and the target wikis.
Fri, Jun 7
May 21 2019
May 15 2019
May 7 2019
May 5 2019
Indeed, this should have already been closed half a year ago.
Apr 30 2019
Apr 26 2019
Apr 22 2019
For now, I have kept a list of existing Wikipedia pages without revisions in my userspace at User:GeoffreyT2000/T112282. The script, if successfully run, would make all 16 links there turn red.
Apr 13 2019
Apr 10 2019
Mar 30 2019
Mar 28 2019
Thinking about it, I don't think that it is a good idea to update rc_namespace and rc_title for old edits prior to a page move. It is better to say that page A has been created (or edited) and then moved to B than to say that page B has been created (or edited) and then moved from A. This is why Special:NewPages shows "originally created as A" when page A gets moved to another title B. Also, if the page had previously been added to or removed from a category prior to the move, then the comment for the corresponding RC entry would still link to the old title, and comments generally should be permanent.
Mar 27 2019
Mar 19 2019
Mar 6 2019
The part about rc_bot has already been fixed with https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/494619/. Perhaps
Jack Phoenix and Lewis Cawte could also make a similar patch that fixes the problem for rc_patrolled.
Mar 5 2019
Mar 2 2019
Feb 28 2019
Feb 27 2019
Feb 26 2019
Feb 25 2019
If this were to be implemented, then that would mean that Special:NewPages would no longer need to show "originally created as" for moved pages. Also, deleting a page would only need to delete RC entries with matching rc_cur_id, not those with matching rc_namespace and rc_title. Otherwise, if page A were to be moved over an existing page B, then all of the edits prior to the move might immediately disappear from recent changes! We could also create a maintenance script that retroactively fixes rc_namespace and rc_title to be the current namespace and title for the page whose ID is given by the rc_cur_id for all existing revisions in the recentchanges table.
Feb 17 2019
Feb 15 2019
Fixed with T199066.
Feb 14 2019
Dec 26 2018
Dec 15 2018
Yes, we use the comment table now in lieu of rev_comment, ar_comment, log_comment, etc.
Dec 13 2018
Dec 12 2018
Another disadvantage I forgot to list above is that if one first restores only the first n deleted revisions, and then restores the later revisions after, one would have to revert the page to how it was before it was deleted. Of course, a similar problem would also occur when one erases the last n revisions' metadata from an XML file prior to importing, and then importing only the later revisions after undoing the erasure of the last n revisions from the XML file and erasing the earlier revisions instead, but usually we leave the XML file alone and import all of the revisions in one step. In fact, we should never generate a null revision when deleting a page, because it is pointless and if one were to be generated, it would always be based on the latest deleted revision (ar_parent_id), yet we allow partial undeletions that restore only the first n revisions. Also, we should generate a null revision on undeletion only when restoring deleted revisions for an existing page.
Dec 11 2018
Dec 6 2018
Dec 5 2018
Dec 2 2018
The idea of generating null revisions on deletions and undeletions has some disadvantages:
- On a wiki with $wgDeleteRevisionsLimit set to a nonzero value n, an administrator without the "bigdelete" right could theoretically delete and undelete a page originally having a single revision half as many times as n each, and then would no longer be able to delete the page again after that.
- In order for page A to be able to be moved to an existing title B by a non-admin, B must be a redirect to A with just a single revision in its history. If an administrator deletes and then undeletes page B, A would no longer be able to be moved to B by a non-admin.
- If one leaves the checkbox for the null revision corresponding to a deletion event unchecked on Special:Undelete, then the page history would only show a null revision for the undeletion event, not the deletion event.
- The rollback link on the history page would no longer make sense after deleting and undeleting a page, unless the user doing the deletion and undeletion was also the last user to edit the page prior to deletion.
- Thanking a null revision for a deletion or undeletion would generate a confusing "Thanker thanked you for your edit on Foo" notification. It is better to use log thank instead for deletions and undeletions, which would generate a "Thanker thanked you for your action relating to Foo" notification.
Fixed after Special:Log started using OOUI.
Nov 17 2018
The logs below will need to be accounted for in T33628:
- User (talk | contribs) created page A — A becomes a blue link
- User (talk | contribs) imported A by file upload (# revisions) (or User (talk | contribs) imported A from (interwiki prefix):title (# revisions)) — A becomes a blue link
- User (talk | contribs) restored page A (# revisions) — A becomes a blue link
- User (talk | contribs) moved page A to B (or User (talk | contribs) moved page A to B without leaving a redirect) — B becomes a blue link
- User (talk | contribs) deleted page A — A becomes a red link
- User (talk | contribs) moved page A to B without leaving a redirect (or User (talk | contribs) moved page A to B over a redirect without leaving a redirect) — A becomes a red link
Nov 11 2018
Nov 10 2018
No longer a problem.
Nov 8 2018
Oct 27 2018
Oct 24 2018
Oct 21 2018
This is really an issue in the MediaWiki core rather than the PageTriage extension. I will upload a patch for this.
Oct 18 2018
Oct 12 2018
Oct 10 2018
Sep 30 2018
Sep 27 2018
I have started an RfC for @kaldari's proposal above at Wikipedia talk:Articles for deletion#RfC: Stop creating separate AfD pages for renominations. If that proposal passes, then this task should be closed as declined.