T296035 Redirects created from page moves should not be included in the edit count (original) (raw)

Redirects created from page moves should not be included in the edit count

Closed, ResolvedPublicBUG REPORT

List of steps to reproduce (step by step, including full links if applicable):

What happens?: The user's edit count is increased by 2.

What should have happened instead?: The user's edit count is increased by 1.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

The change in edit count occurs for each individual move. So, if a page moved had a talk page, then two changes in the user's edit count would occur (one for the subject page move and another for the talk page move).

This is caused by Change 708357, which uses PageUpdater to create the redirect page, thus initiating another (probably undesirable) increment of the edit count.

Related Changes in Gerrit:

Event Timeline

Comment Actions

Is there evidence this was not the case before? These are two distinct actions: page move = 1 edit; redirect creation = 1 edit. That's 2 edits in total.

The redirect creation is considered completely separate action even though it happens as a by-product in some sense, but it does much more than that since a new author and creation timestamp is recorded making it a complete new (redirect) page.

Comment Actions

Let's make this a blocker for MW 1.39. If the change gets merged in master, then I will backport it to 1.38.

Comment Actions

The idea that something this trivial should block a release is utterly ridiculous.

Comment Actions

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

Comment Actions

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

There has never been a "bug". The behavior prior to the PageUpdater change has always been to increment the edit count by 1 for each move, with no additional increment for the redirect. Now, with PageUpdater being used to create the redirect, PageUpdater will also increment the edit count for the redirect. The correct behavior is to treat the null edit and the redirect as the same move, not as separate edits, when updating the edit count. So, the original change actually introduced a bug, not fixed one.

Comment Actions

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

There has never been a "bug". The behavior prior to the PageUpdater change has always been to increment the edit count by 1 for each move, with no additional increment for the redirect.

That definitely sounds like a bug to me; two entries in RecentChanges but only one edit increment. Clearly, you think otherwise.

Now, with PageUpdater being used to create the redirect, PageUpdater will also increment the edit count for the redirect. The correct behavior is to treat the null edit and the redirect as the same move, not as separate edits, when updating the edit count. So, the original change actually introduced a bug, not fixed one.

Right, so even though you say there's a bug in incrementing by 2 instead of 1, your changes don't fix it, but instead fix a different one, of incrementing by 3 instead of 2?

Comment Actions

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

There has never been a "bug". The behavior prior to the PageUpdater change has always been to increment the edit count by 1 for each move, with no additional increment for the redirect.

That definitely sounds like a bug to me; two entries in RecentChanges but only one edit increment. Clearly, you think otherwise.

Now, with PageUpdater being used to create the redirect, PageUpdater will also increment the edit count for the redirect. The correct behavior is to treat the null edit and the redirect as the same move, not as separate edits, when updating the edit count. So, the original change actually introduced a bug, not fixed one.

Right, so even though you say there's a bug in incrementing by 2 instead of 1, your changes don't fix it, but instead fix a different one, of incrementing by 3 instead of 2?

Neither the current code nor the proposed new code will increment the edit count by 3 for any move. The current code does two increments for each move leaving a redirect behind, one for the move and another for the redirect. With the proposed new code, the non-PageUpdater increment in MovePage.php will only happen if the redirect is suppressed. If the redirect is left behind, then that increment is redundant, since another increment is already done with PageUpdater creating the redirect.

GTrang renamed this task from Moving a page with a redirect left behind should only count as one edit to Redirects created from page moves should not be included in the edit count.Jan 15 2025, 5:10 AM

GTrang closed this task as Resolved.

GTrang claimed this task.

Comment Actions

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits