Steps to reproduce
(pages A and B are only examples)
Expected behaviour
RecentChanges should update entries so changes leads to moved page
Actual behaviour
RecentChanges no leads to moved page. See: https://snag.gy/z6RVbB.jpg
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Update past recentchanges entries when user moves a page | mediawiki/core | master | +14 -13 |
Are there certain mw.log entries, like previous page moves, whose recentchanges rows should be left alone rather than changed when the page is moved? If so, what's the list of exclusions? Anyway, for now I just went ahead and excluded all mw.log entries from being changed by this.
Change 492470 had a related patch set uploaded (by Setian; owner: Setian):
[mediawiki/core@master] Update past recentchanges entries when user moves a page
The page link is indeed red and represents the title at the time.
But, does the "diff" link work?
As it is now in the unpatched MediaWiki, if you have a page "Foo" and move it to "Bar" without leaving a redirect, the diff link will still direct you to index.php?title=Foo&curid=... but when you go there, it will say "Difference between revisions of "Bar"" and show you the diff.
And after this change, that would still be the case, right? That seems to be working as expected. Anyhow, I'll leave this for Growth to triage :)
Yes, it will show you the same diff but it will put the updated title as a parameter to index.php.
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.
Some advantages if implemented:
Regardless, if this turns out to be controversial, then it should be turned into a TechCom-RFC.
This looks to be automagically taken care of (going forward) when this patch is applied. The "originally created as" simply doesn't appear for newer entries.
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!
Maybe we just shouldn't delete RC entries when pages are deleted. See T217089.
I have amended the patch to take into account your comment, though.
Change 492470 abandoned by WMFOffice:
Update past recentchanges entries when user moves a page
Reason:
abandoning patch sets of globally banned user
@Trizek-WMF -- I want our team to be able to decide how to proceed. Could you take a look at this, so you and I can discuss it?
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.
If you really wanted all old edits prior to moves to show the new title in Special:RecentChanges, then you can just run rebuildrecentchanges.php. That script will also regenerate RC entries for edits that have been deleted and then restored, as well as edits prior to a move when the redirect has since been deleted or the move has since been undone. Unfortunately, the script currently does not regenerate page categorization entries yet, but I hope that it will one day (T178038).
Of course, deleting a page could also temporarily result in redlinked RC entries. Redlinked RC entries could also occur when adding a page to a redlinked category, or removing a page from such a category.
If anyone else agrees, then this task should be declined.
We talked about this on the Growth team, in a conversation with @Catrope and @Trizek-WMF. We think that since we haven't heard any strong justification for this change, and since no other users have asked for it, that we don't want it to be merged. We are concerned that we would be changing behavior needlessly. If people have strong justifications for why the behavior in RecentChanges should be different, then let's definitely have that conversation. I am declining this task.
