Page MenuHomePhabricator

RecentChanges should update entries when user move a page
Closed, DeclinedPublic

Description

Steps to reproduce
(pages A and B are only examples)

  1. Make page A
  2. Make change at page A
  3. Move page A to page B without leaving redirect

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

Event Timeline

Restricted Application added a project: Growth-Team. · View Herald TranscriptFeb 9 2019, 2:11 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Setian added a subscriber: Setian.EditedFeb 23 2019, 11:14 AM

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

https://gerrit.wikimedia.org/r/492470

The page link is indeed red and represents the title at the time.

But, does the "diff" link work?

Setian added a comment.EditedFeb 24 2019, 4:36 PM

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.

Krinkle added a comment.EditedFeb 24 2019, 7:17 PM

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 :)

Krinkle removed a subscriber: Krinkle.Feb 24 2019, 7:17 PM

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:

  • T43351 would be also be fixed for the Nuke extension.
  • Special:NewPages would no longer show pages in the "wrong" namespace.
  • Moving a page and then deleting the redirect would no longer make the edits prior to the move disappear from recent changes.

Regardless, if this turns out to be controversial, then it should be turned into a TechCom-RFC.

Setian added a comment.EditedFeb 25 2019, 8:25 PM

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.

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.

Aklapper removed Setian as the assignee of this task.Mar 2 2019, 5:17 PM

Change 492470 abandoned by WMFOffice:
Update past recentchanges entries when user moves a page

Reason:
abandoning patch sets of globally banned user

https://gerrit.wikimedia.org/r/492470

JTannerWMF added a subscriber: JTannerWMF.EditedMar 19 2019, 5:59 PM

Hey can you take a look at this and determine how we should proceed @MMiller_WMF

@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.

MMiller_WMF closed this task as Declined.Apr 2 2019, 5:08 PM
MMiller_WMF added a subscriber: Catrope.

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.